wait() & negative values

[Doug McCallum]

In article <70400015 at m.cs.uiuc.edu> carroll at m.cs.uiuc.edu writes:
...
>subprocesses under ISC 2.0.2. While part of this was errors on my part, I've
>recently tracked at least some of the crashes down to the fact that wait(loc)
>sometimes returns negative values in *loc, e.g. 0xFFFFxxyy  where xx and yy
>are the values you'd normally expect in the bottom 16 bits of the return value.
>TFM specifies the contents of the bottom 16 bits of *loc, but says absolutely
>nothing about the top 16 bits. The GNU-Emacs process internals assume that
>the value is positive, in particular that the type and mark bits are 0
>(generally the top 8 bits). A simple fix is to use 
>	w &= 0xFFFF;
>immediately after the wait. Is this reasonable? Does Emacs make unwarranted
>assumptions about wait(), or is this an ISC bug?

The wait call only specifies the bottom 16 bits.  In the V.3 implementation,
only those 16 bits are ever set so the "w &= 0xFFFF;" is reasonable.  I
checked the source and it looks like a bug in the AT&T code.  The exit()
call has its argument shifted left 8 bits and is stored in a "short" in
the proc structure.  When wait is called, that short is put into an "int"
for return to the caller.  If the exit call had been made with a negative
number, or the value when shifted left set the sign bit, the sign will get
extended.  This looks like a pretty generic AT&T behavior.

Doug McCallum
Interactive Systems Corp.
dougm at ico.isc.com