24 Jun
2024
24 Jun
'24
9:17 p.m.
On Mon, Jun 24, 2024 at 8:33 AM Dan Cross <crossd(a)gmail.com> wrote:
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
On Mon, Jun 24, 2024 at 10:12 AM Theodore Ts'o
<tytso(a)mit.edu> wrote:
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.
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.
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. 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.
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)
(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? :-)