Re: function return pointer of int?
- From: Tim Rentsch <txr@xxxxxxxxxxxxxxxxxxx>
- Date: 19 Nov 2008 18:06:39 -0800
Harald van =?UTF-8?b?RMSzaw==?= <truedfx@xxxxxxxxx> writes:
On Mon, 17 Nov 2008 15:45:50 -0800, Tim Rentsch wrote:
This reasoning implicitly assumes that the term "value" has only one
meaning. The standard uses "value" to mean different things in
different places.
No, it doesn't -- and if it did, it would be wrong. The definition of
value is given in the standard (3.17), so when the standard refers to a
value, the meaning is always as defined. (Note that "indeterminate value"
has a definition of its own, and should not be read in its ordinary
English meaning of a value(3.17) that is indeterminate.)
Okay, let's go with your assumption and see where that gets us.
Evaluating the operand expression 'f(0)' does not produce a "pointer";
it produces a value, an object or function designator, or nothing at all
(6.5p1).
It produces a value of pointer type. I called that a pointer; if you don't
want to, I have no problems with that.
If the pointer points to an object that is past the end of its lifetime,
then it may be a trap representation, which is not a value of pointer
type. It can't be both a value of pointer type and /not/ a value of
pointer type.
By the way, according to 3.17, a "value" is the meaning of the
contents of an object. Using this definition, no expression can
produce values, since meanings cannot be stored in computers.
We can be more specific: by 6.5.2.2p5, if 'f(0)' is a legal call and
does not return (void), it produces a value. If the result of 'f(0)' is
a trap representation and so the value is undefined, the result is
undefined behavior.
Given that f(0) produces a value, it is not a trap representation as the
function result. (However, this does not mean you can store it in an
object. The value is indeterminate, and storing it may try to store a trap
representation.)
Your reasoning step is wrong. Expressions produce values only when
they work; the result not being a trap representation is a
/requirement/ for an expression to produce a value, not a consequence.
This possibility is identified specifically in 6.5 p5:
If an exceptional condition occurs during the evaluation of an
expression (that is, if the result is not mathematically defined
or not in the range of representable values for its type), the
behavior is undefined.
The result of 'f(0)' is not in the range of representable values for
its type, since the object previously pointed at is past the end
of its lifetime.
More generally, there is no way to supply an operand to == that is a
"pointer", because evaluating any operand expression always produces a
value, an object or function designator, or nothing at all.
As above.
Again, if the result of an expression is not in the range of
representable values for its type, no value is produced.
That's funny. In your earlier posting you cite a section that clearly
shows that the notion of representation applies outside of any stored
object, and then claim that representation matters only inside an
object.
It's also funny how you conveniently ignore that I added that I did not
see how that section made sense, given the definitions used by the
standard, and otherwise ignored it because it was not important for the
rest of my message at the time.
Hmmmm. You point out an inconsistency, say explicitly that it doesn't
make sense, and then ignore it since it didn't support your argument?
You're right, I shouldn't have ignored you saying it didn't make
sense -- I should have pointed it out! I must be slipping. :)
Somewhat more seriously, it doesn't make sense only because of the
faulty assumption that the word "value" is used with only one meaning.
Occam's Razor leads to a more satisfactory explanation - the
simpler assumption is that the writing isn't careful to use
"value" with only one meaning.
Certain object representations need not represent a value of the
object type. If the stored value of an object has such a
representation
Do you see that the section I cited uses the term "value" more than
once? Do you see that the meanings in the two cases are not the same?
I do now.
Are you claiming the Standard is wrong in what terms it uses to define
the language
I wasn't, but am now.
-- that people should use your terminology rather than the words
actually used in the Standard?
No. The standard should use its own definitions. "value" has a specific
definition. It's not something I made up, it's in the standard and you can
look it up yourself.
It should use its own definition... but it doesn't (at least in some
places)? You agree that it's used with more than one meaning -- so
you're retracting the claim that the term "value" is used with only
one meaning?
I think you're reading more into "value" than what the standard
actually says.
I notice the last statement is simply a deflecting comment and ad
hominem remark (and also made without any supporting evidence).
Excuse me? What I said can be rephrased as roughly "I think the standard
doesn't actually say what you claim it says." and the rest of my message
already explained why I thought so.
Perhaps being more careful with what wording is used to express your
thoughts will lead to better communication.
That notwithstanding, neither phrasing adds any useful information
towards resolving the issue; both are deflecting comments.
The term "value" is used extensively in the Standard. [...] In some
places it's used in
the sense of "contents of an object", as for example 6.5.2.4p5, talking
about ++/-- operators:
After the result is obtained, the value of the operand is
incremented.
Of course, that's absurd, values can't incremented; what's meant is
that the contents of the object holding the value is incremented. But
the Standard does use the term "value".
Interesting. "One is added to the value of the operand" makes perfect
sense with 3.17's definition of value: it means (operand)+1 is evaluated.
What the standard fails to mention is that the result of the addition is
stored back in ++'s operand.
Yes, "One is added to the value of the operand" would fit better, but
that's not what the Standard says; what it does say makes sense only
if the term "value" has a different meaning than the one in 3.17.
In a fair number of places "value" is used to mean representation value:
6.2.4p5,
Indeterminate value -- see above.
I think you may have missed the point here. What's said is "The
initial value of the object is indeterminate." What's meant is "The
initial contents of the object is an indeterminate value." It doesn't
make sense to put "indeterminate value" in place of "value" in the
original -- "The initial indeterminate value of the object is
indeterminate" is just silly. It's true that the word "value" is
meant to be coupled with the word "indeterminate" here, but it also
serves another purpose, identifying the contents of an object.
There's a similar example in 6.2.6.1p6, "The value of a structure or
union object is never a trap representation". Both of these use
"value" to mean "representation value" (or perhaps "contents",
which is basically the same thing if we have an object of a known
type).
6.2.6.1p5,
Agreed.
6.2.6.2p3,
Not at all. The bitwise operators aren't defined in terms of
representation.
Anything that talks about negative zeros is talking about representation,
because negative zero is defined as being a particular representation -
6.2.6.2p2 says:
In the case of sign and magnitude and ones' complement, if this
representation is a normal value it is called a negative zero.
The representation is what's being identified as a negative zero.
6.5.3.2p4,
This makes more sense with 3.17's definition than with yours. An invalid
value, when applied to the * operator, is a value such as a null pointer
or a pointer past the end of an array. If the operand is an lvalue holding
a trap representation, the behaviour is already undefined before the *
operator is evaluated.
At some level the phrase "invalid value" must be talking about
representation, not meaning; a trap representation doesn't
mean anything viewed as a value of its type -- it's meaningless
when considered as that type. The definition in 3.17 defines
"value" as the meaning of the contents of an object; it's
the contents that are invalid, in other words meaningless.
6.7.8p9,
Indeterminate value -- see above.
The language is sloppy because "indeterminate" is used as an adjective
rather than as part of a compound noun, but if that's taken into
account I agree that the contents of the object are meant to
hold an indeterminate value.
6.8.4.2p7
Indeterminate value -- see above.
Again the language is sloppy and that threw me off -- of course what
was meant is printf will access an object whose contents are an
indeterminate value.
are representative examples.
I think it should be clear to anyone who takes the time to look that
"value" is used in the Standard with several different meanings.
I have taken the time to look. I don't agree with your main conclusion.
It's hard to see how you can say that, since you stated earlier
that you saw two uses of "value" that had different meanings.
.
- References:
- Re: function return pointer of int?
- From: Tim Rentsch
- Re: function return pointer of int?
- From: Harald van Dijk
- Re: function return pointer of int?
- From: Tim Rentsch
- Re: function return pointer of int?
- From: Harald van Dijk
- Re: function return pointer of int?
- Prev by Date: Re: slurping in binary data
- Next by Date: Re: slurping in binary data
- Previous by thread: Re: function return pointer of int?
- Next by thread: Re: function return pointer of int?
- Index(es):
Relevant Pages
|
