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
Robert wrote:
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.
Paul wrote
Robert wrote:
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
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 do invoke
On Tue, 2007-01-30 at 07:02 -0500, Paul Schlie wrote:
There is no license to reason about how you think code is
generated, any
compiled is allowed to generate code AS IF a trap representation
were present.
- yes, and thereby inconsistent with reality, and thereby wrong.
(as may and
Paul Schlie wrote:
- as trap representation within the context of C is a value
representation which is not defined to be a member of a type, where if
accessed or produced evokes undefined behavior; so admit as to the best of
my knowledge all potentially enclosable values for IEEE floats and
Paul Schlie wrote:
- yes, and thereby inconsistent with reality, and thereby wrong.
(as may and may not are equivalent possibilities)
The standard is the only reality here. If you cannot deduce semantic
behavior from the semantic model of the standard, then you cannot
deduce it. You are not
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
On Tue, Jan 30, 2007 at 10:49:02AM -0500, Robert Dewar wrote:
Paul Schlie wrote:
- as trap representation within the context of C is a value
representation which is not defined to be a member of a type, where if
accessed or produced evokes undefined behavior; so admit as to the best of
my
Gabriel Paubert wrote:
For all architectures I use, it is rather if used as an operand
of an arithmetic instruction, but the values can be copied
around without ever generating a trap. Even negating or taking
the absolute value never traps since those are not considered
arithmetic
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
Joseph Myers wrote:
DR#260 seems clear enough that indeterminate values may be treated
distinctly from determinate values including randomly changing at any
time. http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm
One can only hope that the recommendations won't see the light of day
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
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 behavior
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 read it?
#
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. http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm
One can only hope that the recommendations won't
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,
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 the
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
mean what
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
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 indeterminate
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 trap
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 from
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 for
* 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 variable
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
assigned to
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.
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.
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
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
Brooks Moses wrote:
http://gcc.gnu.org/ml/gcc/2007-01/msg01119.html ...
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 result
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.
Robert Dewar wrote:
Paul Schlie wrote:
Brooks Moses wrote:
http://gcc.gnu.org/ml/gcc/2007-01/msg01119.html ...
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
Paul Schlie wrote:
Brooks Moses wrote:
http://gcc.gnu.org/ml/gcc/2007-01/msg01119.html ...
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
Paul Schlie wrote:
Brooks Moses wrote:
http://gcc.gnu.org/ml/gcc/2007-01/msg01119.html ...
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
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
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 of an object
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 of an object
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
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
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 you provide
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 you provide
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
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
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 typical
45 matches
Mail list logo
