function return pointer of int?

[jameskuyper]

Re: function return pointer of int?

James Kanze wrote:
....

My main point still holds, of course: no C or C++ compiler will
accept pointer arithmetic on an incomplete type (and void is an
incomplete type). The code simply won't compile.

More accurately: no fully conforming compiler for either language will
accept such code without first issuing a diagnostic. A number of
popular compilers will indeed accept pointer arithmetic on void*,
which is performed as if it were char*. As long as they also issue the
mandatory diagnostic message, they can do so while remaining fully
conforming.

[Keith Thompson]

Re: function return pointer of int?

Michael <michael@michae ldadmum.no-ip.orgwrites:
[...]

change
int * get_p_t(int t) {
to
int * get_p_t(int&t) {

Not in C (note the cross-post).

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Re: function return pointer of int?

James Kanze <james.kanze@gm ail.comwrites:
[...]

My main point still holds, of course: no C or C++ compiler will
accept pointer arithmetic on an incomplete type (and void is an
incomplete type). The code simply won't compile.

Any conforming C or C++ compiler must issue a diagnostic for any
attempt to peform pointer arithmetic on a pointer to an incomplete
type, since it's a constraint violation. At least in C, it's not
actually required to reject the translation unit; it may legally
compile it successfully, and the resulting program has behavior that
is not defined by the standard (though of course it may be defined by
the implementation) .

The only case where a C translation unit *must* be rejected is when it
contains a #error directive that survives preprocessing. I'm not sure
what the corresponding rules are for C++.

In particular, gcc (specifically the C compiler that's part of the gcc
suite) allows arithmetic on void* by default. This is a permissible
extension as long as it issues a diagnostic. g++ doesn't support this
particular extension by default; I don't know whether it has an option
to enable it.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Michael]

Re: function return pointer of int?

Davy wrote:

Hi all,
>
I am writing a function, which return the pointer of the int. But it
seems to be wrong. Any suggestion?
>
int * get_p_t(int t) {
return &t;
}
>
int main()
{
printf("v1\n");
int t = 5;
int * p_t[2];
>
p_t[0] = &t; // right
p_t[1] = get_p_t(t); //wrong
>
return 0;
}
>
Best regards,
Davy

change
int * get_p_t(int t) {
to
int * get_p_t(int&t) {

[Tim Rentsch]

Re: function return pointer of int?

Harald van =?UTF-8?b?RMSzaw==?= <truedfx@gmail. comwrites:

On Wed, 05 Nov 2008 01:26:57 -0800, vippstar wrote:

Please don't quote signatures. (the text after --) Also, no, he can't. I
think his function is valid, ie this code is valid:

int *foo(int i) { return &i; }

However even evaluating foo(anything) invokes undefined behavior, since
the object pointed to by the pointer is over its lifetime, and the
pointer becomes indeterminate. (either unspecified value or trap
representation)

>
You are allowed to call foo. You are even allowed to use its return value
in limited ways (such as comparisons). You are not allowed to store foo's
result in an object, or dereference it.
>
The behaviour dealing with trap representations is only undefined if you
store them in an object ("produced by a side effect that modifies all or
any part of the object by an lvalue expression that does not have
character type"), or read them from an object ("read by an lvalue
expression that does not have character type"). In this code, if you call
foo and discard its result, the return value is never stored in or read
from an object.

Using a trap representation in a value context is undefined behavior
(as I recently explained in another posting, agreeing with the
comments of James Kuyper). The reason is, the semantics are defined
in terms of value, but a trap representation doesn't represent any
value; since there is no definition for how expressions behave when
there is no value, the result is undefined behavior.

An argument could be made that a (void) expression never uses its
value, so perhaps writing 'foo(something) ;' would be allowed.
But any other attempt to use trap representation' s value, including
comparison, would require that what its value is be defined,
and it isn't; ergo, UB.

Actually, I'm not sure how the return value could be a trap representation
at all, since it's a value, and the concept of trap representations
applies to objects, but 6.3.2.2p5 (conversions of integers to pointers) is
a clear example of when a non-lvalue expression may explicitly be a trap
representation.

Section 6.2.6, which clearly is the starting point here, is titled
"Representa tion of types", not "Representa tion of objects". The
first 1.5 sentences of 6.2.6.1 p 5 clarify the distinction

Certain object representations need not represent a value of the
object type. If the stored value of an object has such a
representation

The word "value" is being used in two distinct senses: one, a
point in the value space for the type in question; and two, a
the bits of a stored representation (as might be seen as a value
of, eg., (unsigned char [sizeof (T)]). The result of the function
is held in memory as a "value" in the second sense; any attempt
to use it needs the "value" in the first sense.

It's unfortunate that the Standard uses the term "value" in both of
these senses (and don't even get me started about calling invalid
pointers "trap representations "), but the meaning is clear. It is
a _representation _ value (or (unsigned char [sizeof(T)]) value if
you prefer) that can be a trap representation; a type's value
is defined only if the representation value isn't a trap
representation.

[Tim Rentsch]

Re: function return pointer of int?

Phil Carmody <thefatphil_dem unged@yahoo.co. ukwrites:

Keith Thompson <kst-u@mib.orgwrites :

Puppet_Sock <puppet_sock@ho tmail.comwrites :

On Nov 5, 4:26 am, vipps...@gmail. com wrote:

[...]

>int *foo(int i) { return &i; }
>>
>However even evaluating foo(anything) invokes undefined behavior,
>since the object pointed to by the pointer is over its lifetime, and
>the pointer becomes indeterminate. (either unspecified value or trap
>representation )
>
It only becomes undefined if you try to deref the
pointer that gets returned, because it's a pointer
to a local variable, which has gone out of scope
by the time foo returns. There is no problem with
taking the address, or passing the address around.
But if you try to manipulate things through that
address, you open the gates of undefined.

(Ok, whose sock-puppet are you?)

You're mistaken. If you have a pointer to an object, and that object
then ceases to exists, then the pointer value becomes indeterminate,
and any attempt to evaluate the pointer invokes undefined behavior.

>
What about not doing anything with it?
>
foo(0);
>
It's not being assigned to anything, compared to anything, computed
with, dereferenced, or basically anything that could be said to be
"evaluating " the pointer?

It depends on how you read 6.3.2.2 p 1:

The (nonexistent) value of a void expression (an expression that
has type void) shall not be used in any way, and implicit or
explicit conversions (except to void) shall not be applied to such
an expression. If an expression of any other type is evaluated as
a void expression, its value or designator is discarded. (A void
expression is evaluated for its side effects.)

If you think this conversion needs a value of the (unconverted)
type of the expression, then 'foo(0);' is undefined behavior;
if you think the conversion to (void) discards the function
result without needing a value of type (int *), then it's okay.

[Tim Rentsch]

Re: function return pointer of int?

Keith Thompson <kst-u@mib.orgwrites :

Phil Carmody <thefatphil_dem unged@yahoo.co. ukwrites:

Keith Thompson <kst-u@mib.orgwrites :

Puppet_Sock <puppet_sock@ho tmail.comwrites :
>On Nov 5, 4:26 am, vipps...@gmail. com wrote:
[...]
>>int *foo(int i) { return &i; }
>>>
>>However even evaluating foo(anything) invokes undefined behavior,
>>since the object pointed to by the pointer is over its lifetime, and
>>the pointer becomes indeterminate. (either unspecified value or trap
>>representatio n)
>>
>It only becomes undefined if you try to deref the
>pointer that gets returned, because it's a pointer
>to a local variable, which has gone out of scope
>by the time foo returns. There is no problem with
>taking the address, or passing the address around.
>But if you try to manipulate things through that
>address, you open the gates of undefined.
>
(Ok, whose sock-puppet are you?)
>
You're mistaken. If you have a pointer to an object, and that object
then ceases to exists, then the pointer value becomes indeterminate,
and any attempt to evaluate the pointer invokes undefined behavior.

What about not doing anything with it?

foo(0);

It's not being assigned to anything, compared to anything, computed
with, dereferenced, or basically anything that could be said to be
"evaluating " the pointer?

>
When an expression statement is executed, the expression is evaluated
and its result is discarded. An implementation might reasonably store
the result in an address register; the act of storing an invalid
address in an address register might cause a trap.

Anything an implementation does beyond the semantics of the abstract
machine aren't relevant; in particular the sentence

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.

in 6.2.6.1 p 5 doesn't apply, since stores to an address register
don't correspond to any abstract semantics side effect. Comments
about address registers (or registers in general for that matter)
might tell us /why/ something is undefined behavior, but don't
tell us /whether/ something is undefined behavior.

But Harald made a very interesting point. The pointer value returned
by foo is indeterminate, meaning that it's either an unspecified value
or a trap representation. But a trap representation is not a value.
His argument is that there's no representation (at least as far as the
language semantics are concerned) until and unless the value is stored
in an object.
>
On the other hand, this means that the standard's definition of an
indeterminate *value* as either an unspecified value or a trap
*representation * doesn't make a whole lot of sense.
>
I'm not sure how this should be resolved.

As I just explained responding to Harald's posting, the term "value"
is used in the standard to mean both (a) a point in the space of the
type in question, and (b) a point in the representation space (which
is isomorphic to values in (unsigned char [sizeof(T)])) of memory used
to hold variables and expression results. Obviously I think that
ambiguity should be clarified, but the meaning seems clear.

[Harald van =?UTF-8?b?RMSzaw==?=]

Re: function return pointer of int?

On Mon, 10 Nov 2008 09:36:49 -0800, Tim Rentsch wrote:

Using a trap representation in a value context is undefined behavior (as
I recently explained in another posting, agreeing with the comments of
James Kuyper). The reason is, the semantics are defined in terms of
value, but a trap representation doesn't represent any value; since
there is no definition for how expressions behave when there is no
value, the result is undefined behavior.

Either the trap representation is a value, or the trap representation is
not a value. If it is, for pointer types, 6.5.9p6 defines the behaviour of
comparisons. If it is not, the value simply cannot be a trap
representation.

An argument could be made that a (void) expression never uses its value,
so perhaps writing 'foo(something) ;' would be allowed. But any other
attempt to use trap representation' s value, including comparison, would
require that what its value is be defined, and it isn't; ergo, UB.

See above. Adding 0 to a pointer trap representation is undefined by
omission. Comparing 0 to a pointer trap representation is not, because a
pointer trap representation is by definition a pointer non-value, and
therefore isn't a null pointer, a pointer to an object, or a pointer to
one past the end of an array.

>Actually, I'm not sure how the return value could be a trap
>representati on at all, since it's a value, and the concept of trap
>representation s applies to objects, but 6.3.2.2p5 (conversions of
>integers to pointers) is a clear example of when a non-lvalue
>expression may explicitly be a trap representation.

>
Section 6.2.6, which clearly is the starting point here, is titled
"Representa tion of types", not "Representa tion of objects".

They're the same thing. The representation is how a type is stored in an
object. How a type is stored in a register or any other location is
irrelevant and not addressed by 6.2.6 at all. "Object representation" is
defined in 6.2.6.1p4 and "representation " is clearly used as a shortened
form to mean exactly the same thing in at least 6.2.6.1p8, 6.2.6.2p2, and
6.2.6.2p5.

The first
1.5 sentences of 6.2.6.1 p 5 clarify the distinction
>
Certain object representations need not represent a value of the
object type. If the stored value of an object has such a
representation
>
The word "value" is being used in two distinct senses: one, a point in
the value space for the type in question; and two, a the bits of a
stored representation (as might be seen as a value of, eg., (unsigned
char [sizeof (T)]).

No, that second sense is what's called the object representation, see
6.2.6.1p4. If that's a value at all, it's a series of values of type
unsigned char, not a value of (for example) type int *.

The result of the function is held in memory as a "value" in the second
sense; any attempt to use it needs the "value" in the first sense.

How the result of the function is held in memory is not addressed at all.

It's unfortunate that the Standard uses the term "value" in both of
these senses (and don't even get me started about calling invalid
pointers "trap representations "), but the meaning is clear. It is a
_representation _ value (or (unsigned char [sizeof(T)]) value if you
prefer) that can be a trap representation; a type's value is defined
only if the representation value isn't a trap representation.

I think you're reading more into "value" than what the standard actually
says.

[Tim Rentsch]

Re: function return pointer of int?

James Kuyper <jameskuyper@ve rizon.netwrites :

Keith Thompson wrote:
...

But Harald made a very interesting point. The pointer value returned
by foo is indeterminate, meaning that it's either an unspecified value
or a trap representation. But a trap representation is not a value.
His argument is that there's no representation (at least as far as the
language semantics are concerned) until and unless the value is stored
in an object.

>
More to the point, the only cases associated with trap representations
where the C standard explicitly says the behavior is undefined are the
creation of a trap representation in an object by any method other than
use of an lvalue of character type, or by attempting to access the value
of an object that already contains a trap representation.

Not quite - "by an lvalue expression that does not have character
type" (6.2.6.1 p 5). That's a little different than "any method other
than use of an lvalue of character type". In the second case, the
/absence/ of an lvalue of character type implies undefined behavior;
but in the first case, the /presence/ of an lvalue is required for
(explicit) undefined behavior, and there is UB only if it does not
have character type.

On the other hand, this means that the standard's definition of an
indeterminate *value* as either an unspecified value or a trap
*representation * doesn't make a whole lot of sense.

>
I think that the fundamental problem was the decision of the C committee
to define an indeterminate "value" as including, as one possibility, a
trap "representation ". It should probably have been called an
"indetermin ate representation" , but that would have required rewriting
every place in the standard that currently uses "indetermin ate value",
and the rewrite would be substantially clumsier than the current wording.

I think the fundamental problem is using the term "value" in two
distinct senses, which IMO the standard pretty clearly does. If there
were distinct terms for "a value of type T" and "a representation
value", most of the confusion would go away.

In particular, such a change would make it more complicated to describe
what is going wrong in this particular program: returning a pointer from
a function that becomes invalid precisely because of the fact the
function has returned. Maybe we also need the concept of a "trap value",
distinct from the idea of a "trap representation" ?

The term "trap representation" , as the standard defines it, doesn't
carry over very well into pointer types. At any given point in time,
the set of representation values for a pointer type may be divided
into three sets: one, those representation values that /never/
correspond to actual pointer values; two, those representation values
that /might/ correspond to an actual pointer value but don't at the
moment (an "invalid pointer value"); and three, those representation
values that /do/ correspond to an actual pointer value at this moment
(a "valid pointer value").

Of course, these terms (representation value, invalid pointer value,
valid pointer value) are my suggestions for terms rather than terms
currently used in the standard. I offer them for consideration for
a future revision, or at least to start a discussion about other
suitable terminology (and so crossposting to comp.std.c).

[Tim Rentsch]

Re: function return pointer of int?

Harald van =?UTF-8?b?RMSzaw==?= <truedfx@gmail. comwrites:

On Mon, 10 Nov 2008 09:36:49 -0800, Tim Rentsch wrote:

Using a trap representation in a value context is undefined behavior (as
I recently explained in another posting, agreeing with the comments of
James Kuyper). The reason is, the semantics are defined in terms of
value, but a trap representation doesn't represent any value; since
there is no definition for how expressions behave when there is no
value, the result is undefined behavior.

>
Either the trap representation is a value, or the trap representation is
not a value. If it is, for pointer types, 6.5.9p6 defines the behaviour of
comparisons. If it is not, the value simply cannot be a trap
representation.

This reasoning implicitly assumes that the term "value" has only one
meaning. The standard uses "value" to mean different things in
different places.

An argument could be made that a (void) expression never uses its value,
so perhaps writing 'foo(something) ;' would be allowed. But any other
attempt to use trap representation' s value, including comparison, would
require that what its value is be defined, and it isn't; ergo, UB.

>
See above. Adding 0 to a pointer trap representation is undefined by
omission. Comparing 0 to a pointer trap representation is not, because a
pointer trap representation is by definition a pointer non-value, and
therefore isn't a null pointer, a pointer to an object, or a pointer to
one past the end of an array.

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

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.

Actually, I'm not sure how the return value could be a trap
representation at all, since it's a value, and the concept of trap
representations applies to objects, but 6.3.2.2p5 (conversions of
integers to pointers) is a clear example of when a non-lvalue
expression may explicitly be a trap representation.

Section 6.2.6, which clearly is the starting point here, is titled
"Representa tion of types", not "Representa tion of objects".

>
They're the same thing. The representation is how a type is stored in an
object. How a type is stored in a register or any other location is
irrelevant and not addressed by 6.2.6 at all. "Object representation" is
defined in 6.2.6.1p4 and "representation " is clearly used as a shortened
form to mean exactly the same thing in at least 6.2.6.1p8, 6.2.6.2p2, and
6.2.6.2p5.

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. I guess I should say thank you for making my point for me. :)

The first
1.5 sentences of 6.2.6.1 p 5 clarify the distinction

Certain object representations need not represent a value of the
object type. If the stored value of an object has such a
representation

The word "value" is being used in two distinct senses: one, a point in
the value space for the type in question; and two, a the bits of a
stored representation (as might be seen as a value of, eg., (unsigned
char [sizeof (T)]).

>
No, that second sense is what's called the object representation, see
6.2.6.1p4. If that's a value at all, it's a series of values of type
unsigned char, not a value of (for example) type int *.

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?
Are you claiming the Standard is wrong in what terms it uses to
define the language -- that people should use your terminology rather
than the words actually used in the Standard?

The result of the function is held in memory as a "value" in the second
sense; any attempt to use it needs the "value" in the first sense.

>
How the result of the function is held in memory is not addressed at all.
>

It's unfortunate that the Standard uses the term "value" in both of
these senses (and don't even get me started about calling invalid
pointers "trap representations "), but the meaning is clear. It is a
_representation _ value (or (unsigned char [sizeof(T)]) value if you
prefer) that can be a trap representation; a type's value is defined
only if the representation value isn't a trap representation.

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

The term "value" is used extensively in the Standard. By my counting,
in just sections 1-6, it appears nearly 400 times in more than 200
separate paragraphs. In most of those places it's used in the sense
of "value of a particular type" (or numeric/mathematical value, which
is almost the same thing). In many places it might mean the value of
a particular type or the representation of some value of a particular
type, and it's somewhat ambiguous which. 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".

In a fair number of places "value" is used to mean representation
value: 6.2.4p5, 6.2.6.1p5, 6.2.6.2p3, 6.5.3.2p4, 6.7.8p9, 6.8.4.2p7
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.

[Keith Thompson]

Re: function return pointer of int?

Tim Rentsch <txr@alumnus.ca ltech.eduwrites :
[...]

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

[...]

The standard sometimes uses the term "pointer" in a different way than
you do. A value of pointer type is sometimes referred to as a "pointer".

See for example, C99 7.20.3.3p3:

The malloc function returns either a null pointer or a pointer to
the allocated space.

Personally, I'd be happier if the unqualified term "pointer" referred
only to an object of pointer type, with values of pointer type being
called "addresses" , but that's not how the standard uses the word.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Tim Rentsch]

Re: function return pointer of int?

Keith Thompson <kst-u@mib.orgwrites :

Tim Rentsch <txr@alumnus.ca ltech.eduwrites :
[...]

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

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.

[...]
>
The standard sometimes uses the term "pointer" in a different way than
you do. A value of pointer type is sometimes referred to as a "pointer".
>
See for example, C99 7.20.3.3p3:
>
The malloc function returns either a null pointer or a pointer to
the allocated space.
>
Personally, I'd be happier if the unqualified term "pointer" referred
only to an object of pointer type, with values of pointer type being
called "addresses" , but that's not how the standard uses the word.

Right, the word pointer in the standard sometimes means a value of
pointer type. That's actually what I was trying to get at, although
evidently I didn't express that very clearly. The key thing is that a
/value/ is required, so if what's supplied isn't a value (of type T*)
then the result of doing == is undefined behavior.

[Keith Thompson]

Re: function return pointer of int?

Tim Rentsch <txr@alumnus.ca ltech.eduwrites :

Keith Thompson <kst-u@mib.orgwrites :

>Tim Rentsch <txr@alumnus.ca ltech.eduwrites :
>[...]

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

>[...]
>>
>The standard sometimes uses the term "pointer" in a different way than
>you do. A value of pointer type is sometimes referred to as a "pointer".

[snip]

>
Right, the word pointer in the standard sometimes means a value of
pointer type. That's actually what I was trying to get at, although
evidently I didn't express that very clearly. The key thing is that a
/value/ is required, so if what's supplied isn't a value (of type T*)
then the result of doing == is undefined behavior.

Ah, I see what you mean. The problem was that I only saw 'f(0)';
the definition of f:

int *foo(int i) { return &i; }

had been lost in snippage a couple of articles further upthread. With
that context, what you wrote makes sense.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Harald van =?UTF-8?b?RMSzaw==?=]

Re: function return pointer of int?

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 "indetermin ate 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.)

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.

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

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.

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.

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.

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

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.

In a fair number of places "value" is used to mean representation value:
6.2.4p5,

Indeterminate value -- see above.

6.2.6.1p5,

Agreed.

6.2.6.2p3,

Not at all. The bitwise operators aren't defined in terms of
representation.

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.

6.7.8p9,

Indeterminate value -- see above.

6.8.4.2p7

Indeterminate value -- see above.

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.

[Keith Thompson]

Re: function return pointer of int?

Harald van Dijk <truedfx@gmail. comwrites:

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 "indetermin ate 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.)

[...]

In my opinion, the standard's definition of "value" is incomplete, and
therefore flawed. The definition is:

precise meaning of the contents of an object when interpreted as
having a specific type

This seems to exclude the result of an expression, which is
"obviously" a value as well. Or is it the intent that the result of
an expression doesn't become a "value" until it's stored in an object?

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"