15 Mar
2017
15 Mar
'17
8:14 p.m.
Random832 <random832(a)fastmail.com> 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@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/