Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Sun, 24 Mar 2024 17:27:12 +0100
Organization: A noiseless patient Spider
Lines: 109
Message-ID: <utpk90$f8q6$1@dont-email.me>
References: <bug-20240320191736@ram.dialup.fu-berlin.de>
 <20240320114218.151@kylheku.com> <uthirj$29aoc$1@dont-email.me>
 <20240321092738.111@kylheku.com> <87a5mr1ffp.fsf@nosuchdomain.example.com>
 <20240322083648.539@kylheku.com> <87le6az0s8.fsf@nosuchdomain.example.com>
 <20240322094449.555@kylheku.com> <87cyrmyvnv.fsf@nosuchdomain.example.com>
 <20240322123323.805@kylheku.com> <utmst2$3n7mv$2@dont-email.me>
 <20240323090700.848@kylheku.com> <utnt30$3v0ck$1@dont-email.me>
 <20240323182314.725@kylheku.com> <utp9ct$cmur$1@dont-email.me>
 <20240324083718.507@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 24 Mar 2024 16:27:12 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="af297f15341d352325f54a52911dae41";
	logging-data="500550"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+agmTByzzDZKncXv1G+NdFWMu8nFQc1sQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:a3dCH1RIJstxhfViInpOmxcIcyw=
Content-Language: en-GB
In-Reply-To: <20240324083718.507@kylheku.com>
Bytes: 6777

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.

> It takes a modicum of inference to deduce that a certain explicitly
> stated requirement doesn't exist as far as observability/conformance.
> 
> We are clearly not imagining the sentences which describe a classic
> translation and linkage model. The argument that they don't matter
> for conformance is different from the argument that we imagined
> something between the lines. It is the inference based on 5.1.2.4 that
> is between the lines; potentially between any pair of lines anywhere!
> 
> Furthermore, the requirents may matter to other kinds of observability.
> 
> In C programming, we don't always just care about ISO C observability.

I agree on that.  The C standards are not the be all and end all of 
things of interest to C programmers.  If it were, we'd never have 
compilers with extensions.

But it /is/ the only thing that matters when you talk about "conforming" 
compilers.

If you want to say that LTO breaks some of the requirements that /you/ 
have for the way /you/ want to do unit testing, that's absolutely fine. 
If you want to say that this applies to many other C developers, I'd 
prefer to see a bit of evidence or justification for the claim, but I'd 
take it seriously - I fully appreciate that people have needs beyond 
what the C standards give them.

But that's not what you have been saying.  You have been saying that LTO 
breaks the requirements of the C standards, and you are wrong about that.

> 
> 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.  I do, however, retain the full toolchain used for a 
project, including all build scripts and flags, libraries and compilers, 
and make sure my builds are reproducible on multiple computers - then 
any testing or reviews of the disassembly remain valid over time.  With 
LTO, at least some parts may need to be re-validated after a build even 
for source code changes to apparently different parts of the program - 
that is a cost that must be weighed against the benefits of LTO.  (I 
have considered doing LTO builds in parallel with non-LTO builds - using 
the LTO builds solely for more advanced static checking, while using the 
more debuggable non-LTO build for the "real" binary.)

I have agreed that there are many reasons why LTO might not be a good 
choice for any given project.  I have merely contended the claim that 
conformity is such a reason.

> If the code is actually a
> an intermediate code that is further translated during linking, that's
> not good; we face the prospect of reviewing potentially the entire image
> each time.  Thus we might want an implementation which has a way of
> conforming to the classic linkage model (that happens to be conveniently
> described).
> 
> 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?

> What is significant is that the concept has support in ISO C wording.
> Such a contract can just refer to that: "our project requires the
> classic translation and linkage model that arises from the translation
> phases descriptions 7 and 8 being closely followed".
> As long as you have a way to disable LTO (or not enable it), you have
> that.
>