This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Signed int overflow behavior in the security context
- From: Paul Schlie <schlie at comcast dot net>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Joe Buck <Joe dot Buck at synopsys dot com>, Robert Dewar <dewar at adacore dot com>, Andreas Bogk <andreas at andreas dot org>, <gcc at gcc dot gnu dot org>
- Date: Sat, 27 Jan 2007 11:23:11 -0500
- Subject: Signed int overflow behavior in the security context
> Richard Guenther wrote:
> On 1/27/07, Paul Schlie <schlie@comcast.net> wrote:
>>>> On Fri, Jan 26, 2007 at 06:57:43PM -0500, Paul Schlie wrote:
>>> Likewise, if the program has an uninitialized variable, the behavior
>>> will differ depending on details of optimization and how variables are
>>> assigned to memory. Heap allocated for the first time might always be
>>> zero (as the OS delivers it that way), turning on optimization might then
>>> result in a nonzero initial value because of reuse of a register.
>>
>> - I would argue that in this circumstance although the resulting value may
>> differ, the results are actually equivalent; as in both circumstances the
>> value returned is the value associated with it's storage location; and as
>> the value of all storage locations are arbitrary unless otherwise well
>> specified; the result may change from run to run regardless of any applied
>> optimizations.
>
> If you read from an uninitialized variable twice you might as well get
> a different result each time. This is exactly the same issue than with
> signed overflow and observable behavior - though as somebody notes
> later - the uninitialized variable case doesn't stir up too many peoples
> mind.
- 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. (but does not require that its
associated storage location be literally referenced multiple times unless
correspondingly declared as being volatile; as in effect variables declared
as being volatile have no guarantee of retaining the value most recently
logically assigned within a single tread of execution, and thereby in effect
are bound to a storage location known to perpetually yield indeterminate
values upon each distinct logically specified reference, but even here the
semantics of the language requires that the reference be literally
performed, and not assumed to yield any value although the value is
undefined).