24 Jun
2024
24 Jun
'24
8:33 p.m.
On Mon, Jun 24, 2024 at 10:12 AM Theodore Ts'o <tytso(a)mit.edu> wrote:
On Sun, Jun 23, 2024 at 04:15:40PM -0400, Stuff
Received wrote:
Also, what is "POSIX" changes over time: new things are added, and
occasionally something is removed. Indeed, a new version was just
released a couple of weeks ago. So what does it mean to say that some
OS conforms to POSIX? Which version? For some very old systems,
particularly those that are no longer being substantially updated but
that may have conformed to an older version of the standard, they may
have credibly claimed "POSIX compliant" at some point in the past, but
time has left them behind.
It is unreasonable to constrain program authors to ancient versions of
standards just because some tiny fraction of people want to use an old
system.
Consider 4.3BSD, for example: it shipped with a compiler that predated
the ANSI C standard, and doesn't understand the ANSI-style function
declaration syntax. Should one restrict oneself to the traditional C
dialect forever? If so, one loses out on the substantial benefits of
stronger type checking. Or consider better string handling functions
that came later (`snprintf` is an obvious example, but I would argue
`strlcpy` and `strlcat` as well). Should we restrict ourselves to
laborious and error-prone shenanigans with `strlen` and `strcpy` just
to keep code running on a Sun4c machine under SunOS 4? I really don't
think so.
- Dan C.
My opinion is that the authors simply did not
have access to other
systems or were not interested. Sometimes, one finds a disclaimer to
that effect. I understand that but I am irked when they claim POSIX
compliance.
I get irked because Posix compliance applies to OS's (a specific
binary release of the kernel plus userspace runtime environment), and
not to applications.
Also, compliance implies that it has passed a specific test process,
after paying $$$$ to a Posix Test Compliance Lab, and said compliance
certificate gets revoked the moment you fix a security bug, until you
go and you pay additional $$$ to the Posix compliance lab. Basically,
it's racket that generally only companies who need to sell into the US
or European government market were willing to play. (e.g., at one
point there were Red Hat and SuSE distributions which were POSIX
certified, but Fedora or Debian never were.)
A project or vendor could claim that there product was a "strictly
conforming POSIX application[1], but that's hard to actually prove
(which is why there is no compliance testing for it), since not only
do you have to limit yourself to only those interface guaranted to be
present by POSIX, but you must also not depend on any behavior which
specified to be "implementation defined" (and very often many
traditional Unix behaviors are technically "implementation defined",
so that VMS and Windows could claim to be be "POSIX compliant
implementation".) So a strictly POSIX conforming application was
likely only relevant for very simple "toy" applications that didn't
need to do anything fancy, like say, networking. (Berkeley sockets couldn't be required because
AT&T Streams. Oh,
joy.)
[1]
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#ta…
Can you tell I'm a bit jaded and cynical about the whole Posix
compliance/conformance thing? :-)
Cheers,
- Ted