RFA: how to handle union wait portably?

[msokolov at ivan dot Harhan dot ORG (Michael Sokolov)]

Alexandre, I guess this one is for you as the maintainer of the build/
portability machinery.

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.

--
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)