Re: A Famous Security Bug

On 23/03/2024 17:07, Kaz Kylheku wrote:

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

On 22/03/2024 20:43, Kaz Kylheku wrote:

On 2024-03-22, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Is the "call" instruction *observable behavior* as defined in 5.1.2.3?

>

>
>

Running a program under a test harness is effectively running a
different program.  Of course it can yield information about the
original program, but in effect you're linking the program with a
different set of libraries.

>
It's a different program, but the retained translation unit must be the
same, except that the external references it makes are resolved to
different entities.

>
That is true - /if/ you make the restriction that the translation unit
is complied completely to linkable machine code or assembly, and that it
is not changed in any way when it is combined into the new program.
Such a setup is common in practice, but it is in no way required by the
C standards and does not apply for more advanced compilation and build
scenarios.

 Well, it's only not required if you hand-wave away the sentences in
section 5.
 You can't just do that!

And it is only required if you read between the lines in section 5 and see things that simply are not there.  You can't just do that!
I believe we are at an impasse here, unless someone can think of a new point to make.
One thing I would ask before leaving this - could you take a look at the latest draft for the next C standard after C23?
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf>
Look at the definitions of the "reproducible" and "unsequenced" function type attributes in 6.7.13.8.  In particular, look at the leeway explicitly given to the compiler for re-arranging code in 6.7.13.8.3p6 and similar examples.  Consider how that fits (or fails to fit) with your interpretation of the translation phases in section 5.