Re: A Famous Security Bug

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

On 23/03/2024 10:20, Richard Kettlewell wrote:

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.

>
I /do/ understand why Kaz thinks the way he does.  I am just trying to
show that his interpretation is wrong, so that he can better understand
what is going on, and how to get the behaviour he wants.

I'm just looking at what very plain, simple sentences are saying and
taking it as-is.

I would be entirely happy to see clearer wording in the standards here,
or at least some footnotes saying what is allowed or not allowed.

The wording isn't unclear in any way, though.

What is needed is equally clear new wording which acknowledges the LTO
model of program construction that is currently not described.

That could be done without changing any of the existing wording.
A new translation phase could be wedged between 7 and 8 stating
that translation units may be optionally partitioned into subsets,
and those subsets subject to further semantic analysis and translation,
resulting in merged translation units.

The standard currently presents a reference model that is squarely based
on traditional technology.

If you read the Rationale for C89, mostly they were concerned with how
different models of linkage treat multiply defined identifers, and
worked out a common specification that allows programs to be portable
among those different linkage models.

Ideas like LTO were not on the radar.

It would be unreasonable to expect them to guarantee the behaviour of
code under new standards when the code did not have guaranteed behaviour
under the old standards.  Using TU boundaries to "get memset to work"
has never been guaranteed.

memset is part of the language. It doesn't have to be a function
in another translation unit that is reached via external linkage.
The inclusion of <string.h> can bring in an inline or at least static
definition. Compilers have treated memset as if it were a built-in
primitive. That is justified. It is not part of my topic about LTO.

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