Sujet : Re: A Famous Security Bug
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : comp.lang.cDate : 23. Mar 2024, 16:36:02
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <utmst2$3n7mv$2@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10
User-Agent : Mozilla Thunderbird
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.
If in one program we have an observable behavior which implies that a
call took place (that itself not being directly observable, by
definition, I again acknowledge) then under the same conditions in
another program, that call also has to take place, by the fact that the
translation unit has not changed.
Yes - again, /if/ you restrict your tools and build processes to make this true. (And though the call may still be there, it is still not observable behaviour, and it may no longer lead to any observable behaviour in the new program.)
Basically, what you are saying is that if you have a compiler and build system that compiles individual translation units into fixed individual object files of linkable machine code, and these units are not recompiled when you link them again in new programs, then the machine code in for the externally linked functions defined in those translation units is not changed.
I don't think anyone will argue with that - it is quite solid, and does not come as news to anybody familiar with compilers and build processes.
The thing you get wrong is believing that the C standards require such a compiler and build system. They don't - and thus all your beliefs (about interaction across translation units) which depend on such a requirement, fall apart.