Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Sun, 24 Mar 2024 09:45:48 -0700
Organization: A noiseless patient Spider
Lines: 83
Message-ID: <86o7b3k283.fsf@linuxsc.com>
References: <bug-20240320191736@ram.dialup.fu-berlin.de> <20240320114218.151@kylheku.com> <20240321211306.779b21d126e122556c34a346@gmail.moc> <20240321131621.321@kylheku.com> <utk1k9$2uojo$1@dont-email.me> <20240322083037.20@kylheku.com> <utkgd2$32aj7$1@dont-email.me> <wwva5mpwbh0.fsf@LkoBDZeT.terraraq.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: dont-email.me; posting-host="ba786330f332cc3d5ff45a8f861eda2e";
	logging-data="509397"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19FMOhlf10oBGPEs+5RAXqp1yFell3YcZ8="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:+xJ7d4M00F6ORsiuUmWMN/pJjF0=
	sha1:MsQPPDkpfCURF1qSfu/HY22sdno=
Bytes: 5423

Richard Kettlewell <invalid@invalid.invalid> writes:

> David Brown <david.brown@hesbynett.no> writes:
>
>> I have tried to explain the reality of what the C standards say in a
>> couple of posts (including one that I had not posted before you wrote
>> this one).  I have tried to make things as clear as possible, and
>> hopefully you will see the point.
>>
>> If not, then you must accept that you interpret the C standards in a
>> different manner from the main compile vendors, as well as some "big
>> names" in this group.  That is, of course, not proof in itself - but
>> you must realise that for practical purposes you need to be aware of
>> how others interpret the standard, both for your own coding and for
>> the advice or recommendations you give to others.
>
> Agreed that the ship has sailed on whether LTO is a valid optimization.
> But it's understandable why someone might reach a different conclusion.
> [...]

Granted that someone might follow reasoning like the comments you
gave.  Even so, some further reflection should be enough for them to
reconsider their original assessment.  In particular, the following:

"A C program need not all be translated at the same time."  This
excerpt from the Standard implies that C programs may be translated
in their entirety all at the same time.

Notice the lead in to section 5.1.1.2 p1, describing translation
phases, says "The precedence among the syntax rules of translation
is specified by the following phases."  All of phases 1 through 8
involve translation, but they are about when various forms of
source recognition take place, not about when code is generated.

The "semantically analyzed" in translation phase 7 is nothing more
than type determination and verifying constraints are not violated.
Nothing about these analyses changes if optimizations are carried
out in translation phase 8.

Notice that translation phase 8 says translator output is collected
into a program image "which contains information needed for
execution in its execution environment."  A reasonable inference
is that all code generation could occur at the end of translation
phase 8, as part of producing that information.

The first two points of paragraph 2 in section 1:
    This International Standard does not specify
      * the mechanism by which C programs are transformed for use
        by a data-processing system;
      * the mechanism by which C programs are invoked for use by a
        data-processing system;

The key phrase in section 5.1.2.3:  "The /least requirements/ on a
conforming implementation are: [...]" [emphasis added].

Nothing in the C standard requires an implementation to generate
executable code.  The output of translation phase 7 could be a
machine-independent intermediate form.  The output of translation
phase 8 could be the same machine-independent intermediate form.
Executing the program could be running an interpreter on the program
"executable" holding only the machine-independent intermediate
parts, and the interpreter might carry out optimizations at run
time.  All of these possibilities are allowed in a conforming
implementation as long as the "least requirements" of 5.1.2.3 are
met.

It's a mistake to draw any firm conclusions based on reading parts
of the standard in isolation.  The C standard has been written as a
cohesive whole, and it's important to understand it in the same way.

Related to that, although the C standard gives explicit definitions
for many words and phrases, it also uses words that it does not
define (and presumably are not defined in any of the normative
references, though that may be difficult to verify).  When
confronted with one of these non-defined terms, often arguments are
made that a word means X or Y or Z, because of ... (fill in the
blank).  It's important to remember that, whatever the case is for X
or Y or Z, what /we/ think doesn't matter;  all that does matter is
what the standard's authors (and members of the ISO C committee)
think.  The C standard means what the ISO C group thinks it means.
They are the ultimate and sole authority.  Any discussion about what
the C standard requires that ignores that or pretends otherwise is
a meaningless exercise.