From: schily@schily.net (Joerg Schilling)
Subject: [TUHS] Does this mean Linux is now "officially branded UNIX"?
Date: Wed, 15 Mar 2017 15:14:38 +0100 [thread overview]
Message-ID: <58c94c4e.ywmehec4cxSvdppy%schily@schily.net> (raw)
In-Reply-To: <1489585365.3442859.912122976.442EDB92@webmail.messagingengine.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]
Random832 <random832 at 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 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/
next prev parent reply other threads:[~2017-03-15 14:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-12 15:04 Josh Good
2017-03-13 10:15 ` Joerg Schilling
2017-03-14 13:58 ` Nemo
2017-03-14 14:14 ` Joerg Schilling
2017-03-14 23:27 ` Josh Good
2017-03-15 11:11 ` Joerg Schilling
2017-03-15 13:42 ` Random832
2017-03-15 14:14 ` Joerg Schilling [this message]
2017-03-15 15:16 ` Random832
2017-03-13 21:06 ` Michael-John Turner
2017-03-13 21:35 ` Clem Cole
2017-03-14 10:20 ` Joerg Schilling
2017-03-14 11:35 ` Tim Bradshaw
2017-03-13 21:51 ` Josh Good
2017-03-14 0:11 ` Wesley Parish
2017-03-13 22:30 ` Arthur Krewat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58c94c4e.ywmehec4cxSvdppy%schily@schily.net \
--to=schily@schily.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).