Random832 wrote: > What was the rationale for including the requirement we are discussing? > Even granting that it *did* (there doesn't seem to be any version of the > standard online early enough not to have the supposed mistake in the > text, present in SUSv2 and Issue 6, of allowing waitid to give an 8-bit > value, so we have only your word) Is it really desirable that the > standard *should* include novel SVR4 features not present in earlier > versions of Unix that do not add any particular value? It seems that you do not understand POSIX the right way. POSIX does not invent new features but rather standardizes existing features present in existing UNIX implementations. The fact that SUS introduced waitid(), obviously intended and correctly worded an interface as defined by SVr4 in 1989. The fact that later versions introduced a different wording has been identified as a bug from the standardization process and this bug has been corrected in the technical corrigendum 2 of the current standard. You may read this at: http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm If you like to understand the real problem, it may be better to give more information about the deviations: - AIX only returns 8 bits from the exit() code but is otherwise correct. - HP-UX behaves similar to AIX - Mac OS X returns the lower 24 bits from the exit() code and sign extends the result. Mac OS X however returns a zeroed out si_pid and si_code and thus it's waitid() is completely unusable. I have no idea how Apple could ever pass the POSIX compliance tests. - Previous *BSD implementations did and Linux does clobber important information early in the kernel and thus would need to change their kernel data flow to make waitid() behave correctly. - FreeBSD did this in July 2015 within 20 hours after reporting - NetBSD did this change last year in April within a few days. - The Linux kernel people have been informed and replied that there is no interest in becomming compliant. - The Cygwin people have been informed and replied that they have been Solaris compatible in the past but now are bug by bug Linux compatible. It seems that AIX did introduce it's bug as a result from lately adopting and being hit by the bug in the standard. AIX in addition release the currently latest release one week before the bug in the standard was fixed. I cannot speak for the other OS. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/