> On Feb 3, 2025, at 5:32 PM, Sean Conner via cctalk <cctalk@classiccmp.org>
> wrote:
>
> It was thus said that the Great ben via cctalk once stated:
>>>
>>> At the root of Open Source is you, the user, have the right to the
>> source code.
>>>
>>> In the early days, that's as far as it went but especially after the
>>> Morris Worm, security became very important, Open Source afforded
>>> users the ability to inspect the code for vulnerabilities in ways that
>>> you could not if all you had was the binaries.
>>
>> But open source should have fixed versions, if possible.
>> Look at C compilers. I need a K&R C compiler for say 8088 build.
>> I might not want the latest C standard.
>> What version has the fewest bugs.
>
> You will have to evaluate the C compiler in question. The C Standard
> covers not only the C language, but of a library as well, so your concerns
> about bugs applies to both the compiler and the library that comes with it.
> And it's not like there's just one C compiler everybody uses.
>
> While a C99 compiler will work with K&R style code, and may very well
> generate better code, there may still be issues because newer C compilers
> take advantage of undefined behavior to optimize the code, to the degree
> that once valid C code now exhibits bugs. For instance, this fragment of
> code:
>
> /* a and b are signed integers */
> if (a + b < a) /* check for overflow */
> handle_it();
>
> may very well be removed because signed overflow in C is undefined, and by
> definition (per the compiler writers) a programmer will never intentionally
> invoke undefined bahavior, the code can be removed because it will never be
> true (and this is current behavior! Really!).
In a great many cases, this isn't "code that once was valid C" but rather code
that always was invalid but in ways that old compilers did not catch or take
advantage of in optimization. There probably are some exceptions, given the
evolving standards.
There are various compiler warning options that are helpful for dealing with
these errors, so you're told that there's something wrong rather than the
compiler just silently doing things you probably didn't expect. I remember
getting a lot of benefit out of the GCC warnings about pointer aliasing -- the
rule that T1 * and T2 * where T1 and T2 are different types won't point to the
same memory location.
paul
