On Mon, Jun 24, 2024 at 10:12 AM Theodore Ts'o <tytso@mit.edu> wrote:
> On Sun, Jun 23, 2024 at 04:15:40PM -0400, Stuff Received wrote:
> > 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.
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.
Certification only lasts a certain amount of time... And the compliance isn't
with POSIX, but POSIX.1-2008 or POSIX.1-2024.
The advantage of POSIX, though, is that it tries to keep up with the changes
in interfaces, tastes, etc. So aiming for it is a useful "fuzzy cloud" of what's
currently most likely to be portable to most modern (read: released in the
last decade or less) systems.
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.
Indeed. Ancient systems in general are best dealt with by some
common sense build hacks. libposix can handle the missing functionality
for people that care about these ancient systems, and "layered" include
systems work for systems that are at least new enough to have #include_next
(and #include "/usr/include/stdio.h" for those that don't). Pushing that job
to a thousand package writers is a loser. I've done this for various older
systems that I've dabbled with and it becomes a question of how much
is enough...
I do similar things to build a few Linux applications on FreeBSD w/o
bothering the authors too much (I fix bugs that don't matter on Linux,
but make my shim layer smaller though). But that's mostly a modern ->
modern so C dialect is identical (enough), and the only troublesome
interfaces are the Linux Specific ones which I map to FreeBSD
functionality. I've never formalized this since I only have a few I care
about that are a bit resistant to accepting FreeBSD patches...
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.
Yea.
- Dan C.
> (Berkeley sockets couldn't be required because AT&T Streams. Oh,
> joy.)
Sockets are standardized these days in POSIX, though. IPv6 is optional,
though if you support it, you have to support it with the interfaces defined.
Same with Raw Sockets. But most of that's there (and been there
since 2008 or earlier)
> [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag_02_02_01
>
> Can you tell I'm a bit jaded and cynical about the whole Posix
> compliance/conformance thing? :-)
Yea, Just because POSIX says so has been a terrible excuse for doing something
silly. FreeBSD has long recognized it. However, in moderation, POSIX is a very good
thing. Exact, pedantic, 100% conformance with no flexibility... isn't.
Warner