<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 3, 2024 at 11:03 AM Michael Matz via Gdb <<a href="mailto:gdb@sourceware.org">gdb@sourceware.org</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">Hello,<br>
<br>
On Wed, 3 Apr 2024, Martin Uecker wrote:<br>
<br>
> The backdoor was hidden in a complicated autoconf script...<br>
<br>
Which itself had multiple layers and could just as well have been a <br>
complicated cmake function.<br>
<br>
> > (And, FWIW, testing for features isn't "complex".  And have you looked at <br>
> > other build systems?  I have, and none of them are less complex, just <br>
> > opaque in different ways from make+autotools).<br>
> <br>
> I ask a very specific question: To what extend is testing <br>
> for features instead of semantic versions and/or supported<br>
> standards still necessary?<br>
<br>
I can't answer this with absolute certainty, but points to consider: the <br>
semantic versions need to be maintained just as well, in some magic way.  <br>
Because ultimately software depend on features of dependencies not on <br>
arbitrary numbers given to them.  The numbers encode these features, in <br>
the best case, when there are no errors.  So, no, version numbers are not <br>
a replacement for feature tests, they are a proxy.  One that is manually <br>
maintained, and hence prone to errors.<br>
<br>
Now, supported standards: which one? ;-)  Or more in earnest: while on <br>
this mailing list here we could chose a certain set, POSIX, some <br>
languages, Windows, MacOS (versions so-and-so).  What about other <br>
software relying on other 3rdparty feature providers (libraries or system <br>
services)?  Without standards?<br>
<br>
So, without absolute certainty, but with a little bit of it: yes, feature <br>
tests are required in general.  That doesn't mean that we could not <br>
do away with quite some of them for (e.g.) GCC, those that hold true on <br>
any platform we support.  But we can't get rid of the infrastructure for <br>
that, and can't get rid of certain classes of tests.<br></blockquote><div><br></div><div>Even assuming a set of standards still leaves issues like supporting a </div><div>wide range of OS versions which may evolve to support different versions</div><div>of the same standard. And then there is the case of standards having</div><div>deliberately implementation defined behavior. Last week, I had to double</div><div>check what malloc(0) and free(NULL) are supposed to do per POSIX. </div><div>Guess what -- implementation defined behavior options.</div><div><br></div><div>And worse, POSIX doesn't define the default attributes for pthreads and</div><div>the associated synchronization objects. These vary widely across OSes.</div><div><br></div><div>Then there are the broken things autoconf checks for. Somehow the</div><div>"broken sed from Solaris" check sticks in my head. Or needing to use</div><div>GNU sed instead of FreeBSD sed to build a mips embedded target.</div><div><br></div><div>And this ignores issues like word size issues. 32 vs 64 bits for one, </div><div>Or weird CPUs where nothing is byte addressable (TI C3x/4x is one </div><div>example).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> This seems like a problematic approach that may have been necessary <br>
> decades ago, but it seems it may be time to move on.<br>
<br>
I don't see that.  Many aspects of systems remain non-standardized.<br></blockquote><div><br></div><div>Again from pthreads, manipulating affinity on multi-core systems and </div><div>having names for pthreads are non-standard but commonly available</div><div>with varying APIs.</div><div><br></div><div>And the standards have plenty of wiggle room in them. Undefined areas</div><div>or deliberately implementation defined.</div><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Ciao,<br>
Michael.<br>
</blockquote></div></div>