dhesi@bsu-cs.UUCP (Rahul Dhesi) (12/15/88)
In article <1886@loral.UUCP> jlh@loral.UUCP writes: >In all his examples [the professor] used wait ( (char *) 0). >I pointed out to him that wait wanted an address in which to stuff a result, >and using 0 was probably not a good idea. Passing a NULL pointer to a function is occasionally used to mean "don't return anything here this time". My 4.3BSD manual allows wait(0). [This probably ought to be wait((union wait *)0) ]. Take a look also at the time() system call. This is really a UNIX issue, and not a generic C issue. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/15/88)
In article <5147@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >My 4.3BSD manual allows wait(0). >[This probably ought to be wait((union wait *)0) ]. No, it ought to be wait((int*)0). wait() has always required a pointer to int; when non-null, the pointed-to int was filled in with the least significant 8 bits meaning one thing and the next 8 bits meaning another (see manual for details). Berkeley's attempt to describe this with a union was totally bogus, because the order of the bitfields is implementation-dependent, and the true meaning of the lowest 16 bits of the int pointed to by wait was system-INdependent. Vendors of 4BSD- based systems either had to make sure that the union was kludged to fit their particular C compiler's allocation of bitfields, or else have customer code written according to the original definition break. I'm pretty sure IEEE 1003.1 went with int*.
chris@mimsy.UUCP (Chris Torek) (12/16/88)
In article <9189@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >... In fact, Berkeley broke the non-null case too by changing >it from pointing to an int to pointing to a "union wait". It should be >a pointer-to-int. For once, I actually agree with Doug Gwyn :-) . The 4.3BSD-tahoe <sys/wait.h> is full of `#ifdef's to determine the byte order for a `union wait'. This is grotesque and---perhaps worse--- insufficient, as a `wait' object contains bitfields as well, and while the ifdef's can account for byte order differences, they do not now do so for bit order differences. Were one to add those, the file would become yet more grotesque. Instead, the various operations that are now bit fields should be done with function-like macros. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris