Re: Signed int overflow behavior in the security context

[prj at po dot cwru dot edu (Paul Jarc)]

Paul Schlie <schlie@comcast.net> wrote:
> One can only hope that the recommendations won't see the light of day in
> their present form, as it's fairly clear that once an unspecified value is
> read (presuming absents of a trap representation), it becomes logically
> visible, and thereby clearly no longer logically indeterminate.

An unspecified value was never indeterminate in the first place.  The
terms are not synonymous.  And an object holding an indeterminate
value does not stop being indeterminate when its value is read;
reading it invokes undefined behavior.  This is true Because The
Standard Says So, no matter how illogical it may seem.

> presuming absents of any possibility of a trap representation for a
> given implementation

That's an unreliable presumption.  As noted in the defect report, a
trap representation can have the same bit pattern as a valid value.
Trapness depends not just on the bit pattern, but also how the bit
pattern was produced.  So even if there are no hardware-level traps,
if you read an indeterminate object, a compiler is allowed to produce
the same behavior as if there were hardware-level traps.

> (as the undefined behavior referenced in the DR is related to a pointer
> becoming indeterminate

*Some* of the DR relates to pointers.  But reading the value of any
object (pointer or otherwise) holding a trap representation invokes
undefined behavior.


paul