Re: Signed int overflow behavior in the security context

Paul Schlie wrote: The root of this discussion was based on whether or not GCC's relatively aggressive assumption that an undefined behavior gave it the reasonable and useful right to presume that any expression which may be interpreted as having undefined semantics may be presumed to either mys

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie wrote: >> is required to be well specified [...] as otherwise the language >> couldn't be utilized to write even the most hardware drivers >> required of all computer systems. > > In a sense, the language *can't* be used to write most hardware > drivers. Drivers d

Re: Signed int overflow behavior in the security context

Paul Schlie wrote: Just as: volatile int* port = (int*)PORT_ADDRESS; int input = *port; supposedly invoking an undefined behavior. is required to be well specified, effectively reading through a pointer an un-initialized object's value, and then assigning that unspecified value to the variab

Re: Signed int overflow behavior in the security context

Paul Schlie wrote: - agreed, and thereby objects having no legitimate trap representation, such as most if not all implementations of integers and floating point objects on most if not all current target machines, and thereby their access does not invoke an undefined behavior. First of all, tr

Re: Signed int overflow behavior in the security context

Paul Schlie wrote: >> Joseph Myers wrote: >> DR#260 seems clear enough that indeterminate values may be treated >> distinctly from determinate values including randomly changing at any >> time. > > One can only hope that the recommendati

Re: Signed int overflow behavior in the security context

Paul Schlie <[EMAIL PROTECTED]> wrote: > Paul Jarc wrote: >> 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. > > - that's not what is says Did you re

Re: Signed int overflow behavior in the security context

Joseph S. Myers wrote: > On Sun, 28 Jan 2007, James Dennett wrote: > >> 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

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie 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 clear

Re: Signed int overflow behavior in the security context

Paul Schlie <[EMAIL PROTECTED]> 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

Re: Signed int overflow behavior in the security context

> Joseph Myers wrote: > DR#260 seems clear enough that indeterminate values may be treated > distinctly from determinate values including randomly changing at any > time. One can only hope that the recommendations won't see the light of

Re: Signed int overflow behavior in the security context

On Sun, 28 Jan 2007, James Dennett wrote: > 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

Re: Signed int overflow behavior in the security context

Paul Schlie wrote: >> Paul Jarc wrote: >>> Paul Schlie <[EMAIL PROTECTED]> 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

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie <[EMAIL PROTECTED]> 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 tra

Re: Signed int overflow behavior in the security context

Paul Schlie wrote: >> Paul Jarc wrote: >>> Paul Schlie wrote: >>> if it has an indeterminate value [...] has no bearing on an rvalue >>> access to a well defined storage location >> You might think so, but that's actually not true in the C standard's >> terminology. It sounds like you interpret "i

Re: Signed int overflow behavior in the security context

Paul Schlie <[EMAIL PROTECTED]> 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 repre

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie wrote: >> if it has an indeterminate value [...] has no bearing on an rvalue >> access to a well defined storage location > > You might think so, but that's actually not true in the C standard's > terminology. It sounds like you interpret "indeterminate value" to

Re: Signed int overflow behavior in the security context

Paul Schlie <[EMAIL PROTECTED]> wrote: > if it has an indeterminate value [...] has no bearing on an rvalue > access to a well defined storage location You might think so, but that's actually not true in the C standard's terminology. It sounds like you interpret "indeterminate value" to mean what

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie <[EMAIL PROTECTED]> wrote: >> your corresponding supporting standard citation to the contrary? > > C99 3.17.2 defines "indeterminate value" as "either an unspecified > value or a trap representation". 6.2.6.1p5 says of trap > representations: "If the stored value

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie <[EMAIL PROTECTED]> wrote: >> your corresponding supporting standard citation to the contrary? > > C99 3.17.2 defines "indeterminate value" as "either an unspecified > value or a trap representation". 6.2.6.1p5 says of trap > representations: "If the stored value

Re: Signed int overflow behavior in the security context

Paul Schlie <[EMAIL PROTECTED]> wrote: > your corresponding supporting standard citation to the contrary? C99 3.17.2 defines "indeterminate value" as "either an unspecified value or a trap representation". 6.2.6.1p5 says of trap representations: "If the stored value of an object has such a repres

Re: Signed int overflow behavior in the security context

> Paul Schlie wrote: >>> Brooks Moses wrote: >>> ... >>> Does that logic work for you? >> >> no, as although a variable's value may not have been previously defined >> within the context of a particular program, a variable's access semantics >> are

Re: Signed int overflow behavior in the security context

Paul Schlie wrote: >> Brooks Moses wrote: >> ... >> Does that logic work for you? > > no, as although a variable's value may not have been previously defined > within the context of a particular program, a variable's access semantics > are orthogon

Re: Signed int overflow behavior in the security context

> Robert Dewar wrote: >> Paul Schlie wrote: >>> Brooks Moses wrote: >>> ... >>> Does that logic work for you? >> >> no, as although a variable's value may not have been previously defined >> within the context of a particular program, a variable's

Re: Signed int overflow behavior in the security context

Paul Schlie wrote: Brooks Moses wrote: ... Does that logic work for you? no, as although a variable's value may not have been previously defined within the context of a particular program, a variable's access semantics are orthogonal to what eve

Re: Signed int overflow behavior in the security context

Brooks Moses wrote: 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. I

Re: Signed int overflow behavior in the security context

> Brooks Moses wrote: > ... > Does that logic work for you? no, as although a variable's value may not have been previously defined within the context of a particular program, a variable's access semantics are orthogonal to what ever value may resu

Re: Signed int overflow behavior in the security context

Paul Schlie wrote: I'm game; how might multiple specified references to the same non-volatileS variable with no specified intervening assignments in a single threaded language ever justifiably be interpreted to validly yield differing values? Sorry, I'm not "game", it's something you should be

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 sta

Re: Signed int overflow behavior in the security context

> 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

Re: Signed int overflow behavior in the security context

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. Agai

Signed int overflow behavior in the security context

> Richard Guenther wrote: > On 1/27/07, Paul Schlie <[EMAIL PROTECTED]> 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 >>> as

Re: Signed int overflow behavior in the security context

* Paul Schlie: >> People always say this, but they don't really realize what they are >> saying. This would mean you could not put variables in registers, and >> would essentially totally disable optimization. > > - can you provide an example of a single threaded program where the > assignment of

Re: Signed int overflow behavior in the security context

On 1/27/07, Paul Schlie <[EMAIL PROTECTED]> 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

Re: Signed int overflow behavior in the security context

> David Daney wrote: >> Paul Schlie wrote: >> (however as you appear to be describing an algorithm attempting to rely on >> the implicit addresses of object storage locations resulting from an assumed >> calling or allocation convention; and as such assumptions are well beyond >> the scope of most

Re: Signed int overflow behavior in the security context

With hind sight, it would appear that as many of these difficulties seem rooted in the historical implicit declaration/conversions of variables/parameters to signed int which has correspondingly tended to be implemented as having wrapping semantics regardless of overflow being undefined; and as typ

Re: Signed int overflow behavior in the security context

Paul Schlie wrote: On Fri, Jan 26, 2007 at 06:57:43PM -0500, Paul Schlie wrote: Robert Dewar wrote: People always say this, but they don't really realize what they are saying. This would mean you could not put variables in registers, and would essentially totally disable optimization. - can yo

Re: Signed int overflow behavior in the security context

>> On Fri, Jan 26, 2007 at 06:57:43PM -0500, Paul Schlie wrote: >> > Robert Dewar wrote: >> > >> > People always say this, but they don't really realize what they are >> > saying. This would mean you could not put variables in registers, and >> > would essentially totally disable optimization. >>

Re: Signed int overflow behavior in the security context

On Fri, Jan 26, 2007 at 06:57:43PM -0500, Paul Schlie wrote: > > Robert Dewar wrote: > > > > People always say this, but they don't really realize what they are > > saying. This would mean you could not put variables in registers, and > > would essentially totally disable optimization. > > - can y

Re: Signed int overflow behavior in the security context

Paul Schlie wrote: Robert Dewar wrote: People always say this, but they don't really realize what they are saying. This would mean you could not put variables in registers, and would essentially totally disable optimization. - can you provide an example of a single threaded program where the a

Re: Signed int overflow behavior in the security context

> Robert Dewar wrote: > > People always say this, but they don't really realize what they are > saying. This would mean you could not put variables in registers, and > would essentially totally disable optimization. - can you provide an example of a single threaded program where the assignment of