Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: James Kuyper <jameskuyper@alumni.caltech.edu>
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Fri, 22 Mar 2024 13:05:49 -0400
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <utkdpd$311sb$3@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 22 Mar 2024 17:05:49 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="a1b08a0f50df3424e24db82030d31985";
	logging-data="3180427"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+RLyrjqw1bina1NnIfyrcC8UdKCZTWmlk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:XWLvKxzBbcnPXa9ye36nGkYyXr4=
In-Reply-To: <20240322083648.539@kylheku.com>
Content-Language: en-US
Bytes: 4257

On 3/22/24 11:50, Kaz Kylheku wrote:
> On 2024-03-21, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
....
>> Link time optimization is as valid as cross-function optimization *as
>> long as* it doesn't change the defined behavior of the program.
> 
> It always does; the interaction of a translation unit with another
> is an externally visible aspect of the C program.

The standard makes no use of the concept of "externally visible aspects".

"The least requirements on a conforming implementation are:
— Volatile accesses to objects are evaluated strictly according to the
rules of the abstract machine.
— At program termination, all data written into files shall be identical
to the result that execution of the program according to the abstract
semantics would have produced.
— The input and output dynamics of interactive devices shall take place
as specified in 7.23.3.
The intent of these requirements is that unbuffered or line-buffered
output appear as soon as possible, to ensure that prompting messages
appear prior to a program waiting for input.
This is the observable behavior of the program." (5.1.2.3p6).

The term "observable behavior" is italicized, an ISO convention
indicating that the sentence in which that term is italicized
constitutes the official definition of that term. Note, in particular,
that the term does NOT mean "behavior which can be observed", which
would otherwise be closely connected to your concept of "externally
visible aspects".

Note that "observable behavior" does NOT include function calls, not
even calls to functions defined in different translation units.

The standard explicitly permits optimizations which violate the abstract
semantics, so long as they result in the same observable behavior as if
the abstract semantics had been obeyed. Being able to express that
concept is the only reason that the term "observable behavior" exists.

> ... (That can be inferred
> from the rules which forbid semantic analysis across translation
> units, only linkage.)

I see no wording forbidding such analysis. The section you cite permits
separate translation, but does not forbid whole-program translation.

....
> If I have some translation unit in which there is a function foo, such
> that when I call foo, it then calls an external function bar, that's
> observable.

Not in the sense of "observable behavior" as that term is defined by the
C standard.

....
> Since ISO C says that the semantic analysis has been done (that
> unit having gone through phase 7),

A footnote makes it clear that the translation phases are purely
conceptual, identifying the precedence between the different semantic
rules that they specify. An implementation is not prohibited from
intermingling the translation phases, so long as it produces the same
observable behavior as if it had not intermingled them.


....
> If you have LTO turned on, you might be programming in GNU C or Clang C
> or whatever, not standard C.

True, but you also could be programming in standard C.