This is the mail archive of the gcc@gcc.gnu.org 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:
>> Paul Jarc wrote:
>>> Paul Schlie <schlie@comcast.net> wrote:
>>>  x = x ; perfectly fine; as lvaue x clearly designates an object (no trap)
>> Can you cite the part of the standard that says that?  The fact that
>> an expression designates an object does not exclude that object from
>> holding a trap representation.  A trap representation, as defined by
>> the standard (6.2.6.1p5), is unrelated to dereferencing an invalid
>> pointer.  The word "trap" is also sometimes used to refer to
>> dereferencing an invalid pointer, but that's not relevant here, since
>> the standard uses a different definition.
> 
> In context:
> 
> - Certain object representations need not represent a value of the object
> type.
> 
> - If the stored value of an object has such a representation and is read by
> an lvalue expression that does not have character type, the behavior is
> undefined.
> 
> - If such a representation is produced by a side effect that modifies all
> or any part of the object by an lvalue expression that does not have
> character type, the behavior is undefined.41)
> 
> - Such a representation is called a trap representation.
> 
> Means: a trap representation is a value representation which does not
> constitute a valid member of an object's type except if a char; and
> if such an object value representation is read or produced by an lvalue
> expression, the behavior is undefined (because simply any operation which
> produces or attempts to utilize a value whose representation does not
> validly represent a member of that object's type, it's behavior is sensibly
> undefined; i.e. access or store a value having the logical representation
> of the value 7 in association with an object having a specified enum range
> of 0..5, and all bets are off with respect to how that object's value may
> be subsequently interpreted, as such an access may be recognized as being
> invalid and be trapped).
> 
> Just as the dereference of an indeterminate lvalue may be trapped if its
> value is an illegitimate member of that type.
> 
> However as the only thing C says about uninitialized variables is that its
> value will be initialized with an indeterminate value; which could be a trap
> representation, but as most object type implementations inclusive of ints
> don't have any invalid value representations;

Here's a crucial point; int *can* have such invalid
value representations according to the C and C++
standards.  However: in many implementations, all
bit patterns that can be stored in an object of type
int *do* correspond to valid values.

Therefore, a case can be made that *for an implementation
in which a type has no trap values*, an indeterminate
value must correspond to some specific value.  In other
words: reading an uninitialized int is undefined behavior
only if int includes trap representations in a given
implementation.  Otherwise, all we have is an unspecified
(but valid) value, which is a common assumption.

I'm not sure that I like this conclusion, but I've not
seen a really good argument against it.

-- James


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