Re: A Famous Security Bug

On 27/03/2024 22:06, Kaz Kylheku wrote:

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.
 

Users and implementers can agree on requirements that are outside the requirements of the standards - that is certainly true.  A user will require many things of a compiler that are not in the standard - the system it runs on, its speed, its cost, the quality of the error messages, and countless other things.
Those are not mentioned in the C standards, but are without doubt important to users.
However, you can't claim there are things in the C standards that have implications about things that are not related to conformance to the C standards!  And you can't claim that violating something that is based on /your/ requirements outside of the C standards makes a compiler non-conforming in the context of the C standards.
You are free to say that /you/ require a particular behaviour from your compiler, and that LTO violates conformity with /your/ requirements. And you can happily use a reference to the C standards to help explain your additional requirements.  You just don't get to say that the C standards make requirements that they don't contain.

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.

No, not remotely.
My requirements for debugging are not covered in the C standards in any way.  Currently, enabling LTO in gcc makes the code generation difficult for single-step debugging - it is often very difficult to see which assembly instructions match up with which piece of source code.  I fine-tune other optimisation flags too in order to give a better balance (for my own personal definition of "better") between code efficiency and ease of debugging.  I do not suspect gcc LTO of generating incorrect or non-conforming code.
When you choose not to enable LTO, you are making exactly the same kind of decision (except you do so for testability, rather than debugability).

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).
 

That is completely irrelevant to me.  What /is/ relevant, is that code is not moved around too much and it is thus easier to follow when single-stepping or doing other debugging.  I may also disable inlining and other inter-procedural optimisations within units - something that clearly has no relevance to conformity.

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.)

No, we can't.  LTO is fully valid, conforming optimisation that does not affect the abstract semantics of the language in any way.
But it might affect other requirements outside of the C standards and their definition of the semantics of the language.

 This seems like a good thing.

It's a good thing that people get the choice to balance different requirements beyond the C standards.  (And they even get some options that affect conformity, because that is not always important to all users.)

 

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.
 

OK.  Let's try to be clear - "conformance" on its own, in c.l.c., means conformity to the C standards.  If you or I are talking about conforming to a different set of requirements, we need to be explicit about it.