<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 24, 2024 at 8:33 AM Dan Cross <<a href="mailto:crossd@gmail.com">crossd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jun 24, 2024 at 10:12 AM Theodore Ts'o <<a href="mailto:tytso@mit.edu" target="_blank">tytso@mit.edu</a>> wrote:<br>
> On Sun, Jun 23, 2024 at 04:15:40PM -0400, Stuff Received wrote:<br>
> > My opinion is that the authors simply did not have access to other<br>
> > systems or were not interested.  Sometimes, one finds a disclaimer to<br>
> > that effect.  I understand that but I am irked when they claim POSIX<br>
> > compliance.<br>
><br>
> I get irked because Posix compliance applies to OS's (a specific<br>
> binary release of the kernel plus userspace runtime environment), and<br>
> not to applications.<br>
><br>
> Also, compliance implies that it has passed a specific test process,<br>
> after paying $$$$ to a Posix Test Compliance Lab, and said compliance<br>
> certificate gets revoked the moment you fix a security bug, until you<br>
> go and you pay additional $$$ to the Posix compliance lab.  Basically,<br>
> it's racket that generally only companies who need to sell into the US<br>
> or European government market were willing to play.  (e.g., at one<br>
> point there were Red Hat and SuSE distributions which were POSIX<br>
> certified, but Fedora or Debian never were.)<br>
><br>
> A project or vendor could claim that there product was a "strictly<br>
> conforming POSIX application[1], but that's hard to actually prove<br>
> (which is why there is no compliance testing for it), since not only<br>
> do you have to limit yourself to only those interface guaranted to be<br>
> present by POSIX, but you must also not depend on any behavior which<br>
> specified to be "implementation defined" (and very often many<br>
> traditional Unix behaviors are technically "implementation defined",<br>
> so that VMS and Windows could claim to be be "POSIX compliant<br>
> implementation".)  So a strictly POSIX conforming application was<br>
> likely only relevant for very simple "toy" applications that didn't<br>
> need to do anything fancy, like say, networking.<br>
<br>
Also, what is "POSIX" changes over time: new things are added, and<br>
occasionally something is removed. Indeed, a new version was just<br>
released a couple of weeks ago. So what does it mean to say that some<br>
OS conforms to POSIX? Which version? For some very old systems,<br>
particularly those that are no longer being substantially updated but<br>
that may have conformed to an older version of the standard, they may<br>
have credibly claimed "POSIX compliant" at some point in the past, but<br>
time has left them behind.<br></blockquote><div><br></div><div>Certification only lasts a certain amount of time... And the compliance isn't</div><div>with POSIX, but POSIX.1-2008 or POSIX.1-2024.</div><div><br></div><div>The advantage of POSIX, though, is that it tries to keep up with the changes</div><div>in interfaces, tastes, etc. So aiming for it is a useful "fuzzy cloud" of what's</div><div>currently most likely to be portable to most modern (read: released in the</div><div>last decade or less) systems.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It is unreasonable to constrain program authors to ancient versions of<br>
standards just because some tiny fraction of people want to use an old<br>
system.<br></blockquote><div><br></div><div>Indeed. Ancient systems in general are best dealt with by some</div><div>common sense build hacks. libposix can handle the missing functionality</div><div>for people that care about these ancient systems, and "layered" include</div><div>systems work for systems that are at least new enough to have #include_next</div><div>(and #include "/usr/include/stdio.h" for those that don't). Pushing that job</div><div>to a thousand package writers is a loser. I've done this for various older</div><div>systems that I've dabbled with and it becomes a question of how much</div><div>is enough...</div><div><br></div><div>I do similar things to build a few Linux applications on FreeBSD w/o</div><div>bothering the authors too much (I fix bugs that don't matter on Linux,</div><div>but make my shim layer smaller though). But that's mostly a modern -></div><div>modern so C dialect is identical (enough), and the only troublesome</div><div>interfaces are the Linux Specific ones which I map to FreeBSD</div><div>functionality. I've never formalized this since I only have a few I care</div><div>about that are a bit resistant to accepting FreeBSD patches...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Consider 4.3BSD, for example: it shipped with a compiler that predated<br>
the ANSI C standard, and doesn't understand the ANSI-style function<br>
declaration syntax. Should one restrict oneself to the traditional C<br>
dialect forever? If so, one loses out on the substantial benefits of<br>
stronger type checking. Or consider better string handling functions<br>
that came later (`snprintf` is an obvious example, but I would argue<br>
`strlcpy` and `strlcat` as well). Should we restrict ourselves to<br>
laborious and error-prone shenanigans with `strlen` and `strcpy` just<br>
to keep code running on a Sun4c machine under SunOS 4? I really don't<br>
think so.<br></blockquote><div><br></div><div>Yea.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
        - Dan C.<br>
<br>
<br>
> (Berkeley sockets couldn't be required because AT&T Streams.  Oh,<br>
> joy.)<br></blockquote><div><br></div><div>Sockets are standardized these days in POSIX, though. IPv6 is optional,</div><div>though if you support it, you have to support it with the interfaces defined.</div><div>Same with Raw Sockets. But most of that's there (and been there</div><div>since 2008 or earlier)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> [1] <a href="https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag_02_02_01" rel="noreferrer" target="_blank">https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag_02_02_01</a><br>
><br>
> Can you tell I'm a bit jaded and cynical about the whole Posix<br>
> compliance/conformance thing?   :-)<br></blockquote><div><br></div><div>Yea, Just because POSIX says so has been a terrible excuse for doing something</div><div>silly. FreeBSD has long recognized it. However, in moderation, POSIX is a very good</div><div>thing. Exact, pedantic, 100% conformance with no flexibility... isn't.</div><div><br></div><div>Warner</div></div></div>