This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Signed int overflow behavior in the security context

Paul Schlie wrote:
Robert Dewar wrote
Paul Schlie wrote:
-  However x ^= x :: 0 for example is well defined because absent any
intervening assignments, all reference to x must semantically yield the
same value, regardless of what that value may be.
Nope, there is no such requirement in the standard. Undefined means
undefined. Again you are confusing the language C defined in the C
standard with some ill-defined language in your mind with different
semantics. Furthermore, it is quite easy to see how in practice you
might get different results on successive accesses.

I'm game; how might multiple specified references to the same non-volatile variable with no specified intervening assignments in a single threaded language ever justifiably be interpreted to validly yield differing values?

(any logically consistent concrete example absent reliance on undefined
hand-waving would be greatly appreciated; as any such interpretation or
implementation would seem clearly logically inconsistent and thereby
useless; as although the value of a variable may be undefined, variable
reference semantics are well defined and are independent of its value)

I think you and Robert may be talking about different contexts. I'm pretty sure (though not positive) that Robert is talking about the case after an undefined operation has occurred. I'm not sure if you're talking about that, or talking about normal program operation.

In any case, for the "after an undefined operation" context, probably a more useful way to think about it is this: After an undefined operation, there are no guarantees about what code the program will be executing. In particular, there is no guarantee that it will actually be executing the code that you wrote. And thus, any argument that assumes that it's doing so -- for instance, an argument that it's accessing the same location in memory twice, and thus should get the same result both times -- is relying on incorrect axioms.

This comes about because of a more fundamental and crucially important observation: There is _never_ a guarantee about the particular code that a program will be executing -- if there were, this would be assembly language, and optimization would be illegal. The C standard, if it is anything like the Fortran standard, does not say anything at all about what machine code will be executed. The guarantee is that the code that is being executed will have the _same result_ as the code that was written, so long as the written code was legal.

It thus seems pretty easy to see why undefined results can cause programs to act strangely. The compiler is free, under the standard, to write whatever code it wants so long as that code produces the "right" answer to legal operations. There's often no good reason to expect that this code will still produce the "right" answer to illegal operations. C is not assembly language.

Does that logic work for you?

- Brooks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]