Re: RFA: how to handle union wait portably?

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: msokolov at ivan dot Harhan dot ORG (Michael Sokolov) 
 > 
 > In three places where it lauches and waits for child processes (gcc,
 > collect2, and protoize) GCC makes the implicit assumption that the
 > status variable filled in by wait is an int. It always uses an int
 > variable, passes an int * to wait (indirectly via pwait in libiberty),
 > and then applies the W* macros to this int. In system.h where the W*
 > macros are provided for systems that lack them again they are written
 > with the assumption that they need to deal with an int.
 > 
 > This breaks on 4.3BSD, where the process status is a union wait
 > instead of an int, although it has the same size and bit layout as it
 > does on other systems where it's an int. I.e., at the machine level
 > it's exactly the same 32-bit integer with the exact same layout, but
 > the 4.3BSD docs encourage programmers to declare it as union wait and
 > access its fields as union members, rather than declare it as an int
 > and shift and mask it. 4.3BSD's <sys/wait.h> defines union wait and
 > defines WIFEXITED and WIFSIGNALED macros that expect a union wait. It
 > does not define WEXITSTATUS or WTERMSIG because those aren't necessary
 > with a union wait, you just use .w_retcode and .w_termsig instead.
 > 
 > GCC breaks when compiled with itself (like in bootstrap stage 2)
 > because it declares this variable as an int, but uses the WIFEXITED
 > and WIFSIGNALED macros from 4.3BSD's <sys/wait.h>, which expect their
 > argument to be a union wait and apply the dot operator to it, at which
 > GCC instantly squeaks. (I haven't noticed this problem previously when
 > compiling GCC with PCC because PCC, and I know the ISO C folks here
 > will be horrified by this, allows you to apply the dot operator to
 > something that is not a struct or union. It issues a warning, but
 > doesn't abort compilation and produces correct code.) GCC has had this
 > problem since at least 2.8.1 (the earliest I checked) through the
 > current 2.97.
 > 
 > Alexandre (or other portability gurus here), would you happen to have
 > any insight on how to solve this problem in a portable way that
 > doesn't break other systems and would be acceptable for a patch for
 > the current GCC? TIA.

Hmm, you say you have conflicts with sys/wait.h.  But IIRC the test
for sys/wait.h not only checks whether the file exists, but also
whether it is POSIX compatible.  BSD's is not, so you shouldn't see it
get included during bootstrap.  I think that is the cause of your
problems, what does cofigure say for this test?

"checking for sys/wait.h that is POSIX.1 compatible... ???"

If it says "yes", does forcing it to "no" fix your problem,
and can you figure out why it erroneously says "yes"?

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions