Path: ...!feeds.phibee-telecom.net!3.eu.feeder.erje.net!feeder.erje.net!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: Sat, 23 Mar 2024 18:58:21 +0100
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <utn57t$3pbh7$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: dont-email.me; posting-host="78504154b5b778976e0d4e96fcf6a85e";
	logging-data="3976743"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18RyOAXbeGizPfUDMXY7MfSXD9WkPn9vbs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:EHOkaRU5/JqZzCamYRcTvPnehVk=
Content-Language: en-GB
In-Reply-To: <20240323090700.848@kylheku.com>
Bytes: 3422

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.