Re: libc 2.3 and RT signals broken

[GOTO Masanori <gotom at debian dot or dot jp>]

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
 }