Re: libc 2.3 and RT signals broken
At Mon, 28 Oct 2002 21:40:19 -0500,
Daniel Jacobowitz wrote:
> 2002-09-18 Ulrich Drepper <drepper@redhat.com>
>
> * signal/allocrtsig.c: Move to...
> * sysdeps/generic/allocrtsig.c: ...here. New file.
>
> as far as I can tell.
>
> The problem is something I ran into in GDB today: the location of a
> source file overrides the normal search path. If a file in
> sysdeps/generic/ includes a header using "", the copy in
> sysdeps/generic/ will win. So we get sysdeps/generic/testrtsig.h
> instead of the sysdeps/unix/sysv/linux/testrtsig.h, and
> kernel_has_rtsig always returns 0.
>
> So SIGRTMIN is -1. Oops.
>
> Why does allocrtsig.c have to be in sysdeps/generic? If it does need
> to, then we will have to duplicate it in sysdeps/unix/sysv/linux/; but
> since nothing overrides it I don't see why it had to move out of
> signal/.
allocrtsig.c is OK.
This patch fixes the bug. uname(&name) changes 'struct name'. But
evaluation order is not defined (C99 says about in detail), so on i386
gcc evaluates '__strverscmp (name.release, "2.1.70") >= 0' in first
and name.release has no valid value. Thus this function does not work
well.
Please apply this patch.
Regards,
-- gotom
2002-10-29 GOTO Masanori <gotom@debian.or.jp>
* sysdeps/unix/sysv/linux/testrtsig.h: Fix possibly illegal
evaluation order.
--- sysdeps/unix/sysv/linux/testrtsig.h 2001-07-06 13:56:13.000000000 +0900
+++ sysdeps/unix/sysv/linux/testrtsig.h.new 2002-10-29 12:12:20.000000000 +0900
@@ -30,7 +30,9 @@
return 1;
#else
struct utsname name;
-
- return uname (&name) == 0 && __strverscmp (name.release, "2.1.70") >= 0;
+ int ret;
+
+ ret = uname (&name);
+ return ret == 0 && __strverscmp (name.release, "2.1.70") >= 0;
#endif
}
Reply to: