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 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; and as the standard very
clearly requires a trap representation be read or stored by the lvalue
expression to invoke undefined behavior, the only circumstance in which this
may typically validly occur in conventional implementations is upon storing
or reading an pointer, struct or emum object type with an illegitimate
(trap) value representation.




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