Re: A Famous Security Bug

On 2024-03-24, David Brown <david.brown@hesbynett.no> wrote:

On 24/03/2024 17:02, Kaz Kylheku wrote:

On 2024-03-24, David Brown <david.brown@hesbynett.no> wrote:

On 24/03/2024 06:50, Kaz Kylheku wrote:

(So why bother looking.) I mean,
the absolute baseline requirement any LTO implementor strives toward is
no change in observable behavior in a strictly conforming program, which
would be a showstopper.
>

>
Yes.
>
I don't believe anyone - except you - has said anything otherwise.  A C
implementation is conforming if and only if it takes any correct C
source code and generates a program image that always has correct
observable behaviour when no undefined behaviour is executed.  There are
no extra imaginary requirements to be conforming, such as not being
allowed to use extra information while compiling translation units.

 
But the requirement isn't imaginary. The "least requirements"
paragraph doesn't mean that all other requirements are imaginary;
most of them are necessary to describe the language so that we know
how to find the observable behavior.
 

>
The text is not imaginary - your reading between the lines /is/.  There
is no rule in the C standards stopping the compiler from using
additional information or knowledge about other parts of the program.

Sure there is; just not in a way that speaks to the formal notion of
conformance. The text is there, and a user and implementor can use
that as a touchstone for agreeing on something outside of conformance.

In safety critical coding, we might want to conduct a code review of
the disassembly of an object file (does it correctly implement the
intent we believe to be expressed in the source), and then retain that
exact file until wit needs to be recompiled.

>
Sure.  And for that reason, some developers in that field will not use
LTO.  I personally don't make much use of LTO because it makes software
a pain to debug.

So, in that situation, your requirement can be articulated in a way that
refers to the descriptions in ISO C. You're having your translation
units semantically analyzed according to the abstract separation between
phase 7 and 8 (which is not required to be followed for conformance).

We can identify the LTO switch in the compiler as hinging around
whether the abstract semantics is followed or not. (Just we can't tell
using observable behavior.)

This seems like a good thing.

We just may not confuse that conformance (private contract between
implementor and user) with ISO C conformance, as I have.
Sorry about that!
 

>
Are you saying that after dozens of posts back and forth where you made
claims about non-conformity of C compilers handling of C code in
comp.lang.c, with heavy references to the C standards which define the
term "conformity", you are now saying that you were not talking about C
standard conformity?

Certainly not! I was wrongly talking about that one and only
conformance.

Once again, sorry about that.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca