difference

[Jack Klein]

As I undersdand it, &i is a pointer constant (like NULL in a pointer
context, or the name of an array). It's not a object because it's a constant
value. Constant values have no address. Hence, the assertion "a pointer is an
object" sounds good to me. Please, let me know if I'm wrong.

OK, you're wrong. There are pointer rvalues, too, even though the
latest standard does not mention "rvalue" except in a footnote
explaining that the standard uses the term "value of an expression" in
its place.

Consider:

void my_func(char *cp)
{
char *ccp = cp + 1;
}

The expression "cp + 1" produces a value (what used to be called an
rvalue), that is then assigned to the object ccp. The expression
itself, or rather the value it computes, is not an object.

Of course this example is not particularly common, so consider another
one for limiting a loop to the items in an array:

int max_val(int *ip, int how_many)
{
int guess = INT_MIN;
int *p;;

for (p = ip; p < ip + how_many; ++ip)
{
if (*p > guess)
guess = *p;
}
}

There is no object associated with the expression "ip + how_many". It
provides a pure value.

 

[Jack Klein]

Don't fight it so hard. "pointer to the address of" indeed. I contend
simply that we confuse "address" and "pointer" too often. An address is
a value with pointer type but it is a value, not an object. The value
yielded by the & operator is an address. Calling it a pointer is wrong.
Expressing the name of a function yields the address of it. Not a
pointer.

Address is not a C type. If it were a C type, it would be a distinct
type from pointer. Either "address of int" and "pointer to int" are
the same type, meaning they only need one name, or they are different
and therefore incompatible types.

The latter leads to the necessity to write code like this:

int i;
int *ip = (int *)&i; /* &i does not have type "pointer to int" */

const char *fred = (const char *)"fred";

It would be better for the standard to omit the term "address" from
the language. It is an unnecessary low-level term.

 

[pete]

Disagreed. (Would you object to my calling 5 an 'int',

I would call 5 an int, 5.0f a float, and 5.0 a double.

even though
it's not an object? ...And that's not even getting into the debate
that hit c.s.c a year or so ago, when it seemed like maybe 5 *was*
an object, just not an lvalue... I don't remember the details.)

In C99, an expression with object type is an lvalue,
except that the C99 standard can't possibley mean
what it says there. All constants have object type.

N869
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not
designate an object when it is evaluated, the behavior is
undefined.

Therefore, the evaluation of any integer constant,
yields undefined behavior, in C99,
except that the standard can't possibley mean what it says there.

 

[Hallvard B Furuseth]

N869
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not
designate an object when it is evaluated, the behavior is
undefined.

Therefore, the evaluation of any integer constant,
yields undefined behavior, in C99,
except that the standard can't possibley mean what it says there.

....unless it means that constants are objects.

 

[pete]

N869
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not
designate an object when it is evaluated, the behavior is
undefined.

Therefore, the evaluation of any integer constant,
yields undefined behavior, in C99,
except that the standard can't possibley mean what it says there.

...unless it means that constants are objects.

ITYM ...unless it means that constants are objects and lvalues.

Do you think that consants are lvalues ?

 

[August Derleth]

And, in the above context:

int *p = c & i;

is probably a silly error, due to the appalling overuse and
overloading of symbols in C in context sensitive manners. We
won't fix this now, but I just thought I would rant and rave a
bit. Wasn't it the Queen of Hearts who said "it means just what I
intend it to mean".

Humpty-Dumpty, but I don't see how parsing that expression could be a
problem. Here's how my mind sees it, in pseudo-assembly:
load r0, [c]
and r0,
store r0, [p]
Is that at variance with the definition of & in this context? I mean, it
probably isn't a highly intelligent use of the bitwise-and, but it parses.

 

[Irrwahn Grausewitz]

I would call 5 an int, 5.0f a float, and 5.0 a double.

In clc-pedantic-mode I would call 5 an integer constant, etc.
;^)

In C99, an expression with object type is an lvalue,
except that the C99 standard can't possibley mean
what it says there.

I suspect you somehow reversed the logic, see below...

All constants have object type.

N869
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not
designate an object when it is evaluated, the behavior is
undefined.

Therefore, the evaluation of any integer constant,

- when used as an lvalue -

yields undefined behavior, in C99,

which makes sense, since a constant doesn't designate an object
(you cannot take its address).

except that the standard can't possibley mean what it says there.

Why not? I read 6.3.2.1#1 like:

An lvalue *has* to be an expression with an object type(...),
*but* only those expressions with object type(...), that
designate objects, are valid lvalues.

Consider footnote 53 in ISO/IEC 9899:1999:
<quote>
The name "lvalue" comes originally from the assignment
expression E1 = E2, in which the left operand E1 is required
to be a (modifiable) lvalue. It is perhaps better considered
as representing an object "locator value". What is
^^^^^^^^^^^^^^^^^^^^^^
sometimes called "rvalue" is in this International Standard
described as the "value of an expression".
</quote>

Since constants do not designate/locate objects, they should not
be used as lvalues, unless you're in need of nasal demons...

However, that doesn't affect the behaviour when an integer
constant is used as rvalue (its value is used).

Anybody, please correct me, if I'm mistaken.

Regards

 

[pete]

In clc-pedantic-mode I would call 5 an integer constant, etc.
;^)

Does that etc. lead to two different terms
whic distinguish 5.0f from 5.0 ?

In C99, an expression with object type is an lvalue,
except that the C99 standard can't possibley mean
what it says there.

I suspect you somehow reversed the logic, see below...

All constants have object type.

N869
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not
designate an object when it is evaluated, the behavior is
undefined.

Therefore, the evaluation of any integer constant,

- when used as an lvalue -

The standard says what an lvalue is.
and what happens when it is evaluted.
The standard doesn't say anything about usage
affecting what happens when an lvalue is evaluated.

which makes sense, since a constant doesn't designate an object
(you cannot take its address).


Why not? I read 6.3.2.1#1 like:

An lvalue *has* to be an expression with an object type(...),
*but* only those expressions with object type(...), that
designate objects, are valid lvalues.

Consider footnote 53 in ISO/IEC 9899:1999:
<quote>
The name "lvalue" comes originally from the assignment
expression E1 = E2, in which the left operand E1 is required
to be a (modifiable) lvalue. It is perhaps better considered
as representing an object "locator value". What is
^^^^^^^^^^^^^^^^^^^^^^
sometimes called "rvalue" is in this International Standard
described as the "value of an expression".
</quote>

Since constants do not designate/locate objects, they should not
be used as lvalues, unless you're in need of nasal demons...

I agree with your advice, but the standard doesn't say that.

 

[Irrwahn Grausewitz]

Does that etc. lead to two different terms
whic distinguish 5.0f from 5.0 ?

Hmm, since the standard refers to any numerical floating point
constant as, ...err... "floating constant", one could use the
following:

single precision floating constant ( 5.0f )
double precision floating constant ( 5.0 )
long double precision floating constant ( 5.0l )

Still, only when being pedantic, of course...

And somehow I still do.

N869
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not
designate an object when it is evaluated, the behavior is
undefined.

Therefore, the evaluation of any integer constant,

- when used as an lvalue -

The standard says what an lvalue is. Agreed.

and what happens when it is evaluted. Agreed.

The standard doesn't say anything about usage
affecting what happens when an lvalue is evaluated.

I happen to disagree, see below.

I agree with your advice, but the standard doesn't say that.

Huh?!? But in 6.3.2.1 the standard /explicitly/ states that
evaluating lvalues that do not designate objects (integer
constants being one example) invokes UB, which is Standardese
for: "Don't do it!"

That however does not affect the behaviour when evaluating the
same expression in a (r)value context [1], which is of course
well defined elsewhere in the standard.

6.3.2.1 defines which "thingies" qualify as candidates for valid
lvalues, not that these "thingies" are always lvalues. Otherwise
the paragraph would start like: "Expressions with object type
(...) are lvalues (...)" - which in turn would lead to the wrong
conclusion that evaluating an integer constant would invoke
undefined behaviour under all circumstances. - Since it doesn't,
it doesn't...

"Thingies" like 5 aren't lvalues in and of itself. They may
appear in lvalue (object) context, but in this case won't do
any good, as we happen to agree.


Consider:

int i;
int p;
int a[5], b[5];

i = 5; /* fine; i is a valid lvalue and 5 a valid rvalue */
ip = &5; /* invalid; 5 is an lvalue here, but you cannot compute
its address: it's an lvalue that doesn't designate
an object and is therefore unsuitable as an operand
to the unary & operator. [2] */
5 = 6; /* invalid; 5 is an lvalue that doesn't designate
an object and is therefore unsuitable as left
operand of an assignment operator [3], whereas 6 is
a valid rvalue. */
ip = &i; /* fine; ip and i are suitable lvalues */
a = b; /* invalid; a is an lvalue designating an object,
but it is not modifiable [3] */


[1] As opposed to object (lvalue) context.

[2] See C99 6.5.3.2#1
<OT> gcc emits "error: invalid lvalue in unary '&'" </OT>

[3] See C99 6.5.16
<OT> gcc emits "error: invalid lvalue in assignment" </OT>

Regards

 

[Dan Pop]

Hmm, since the standard refers to any numerical floating point
constant as, ...err... "floating constant", one could use the
following:

single precision floating constant ( 5.0f )
double precision floating constant ( 5.0 )
long double precision floating constant ( 5.0l )

Still, only when being pedantic, of course...

Otherwise, we can use their informal names: float constant, double
constant, long double constant.

Dan

 

[pete]

Hmm, since the standard refers to any numerical floating point
constant as, ...err... "floating constant", one could use the
following:

single precision floating constant ( 5.0f )
double precision floating constant ( 5.0 )
long double precision floating constant ( 5.0l )

What int, float and double really are, are types.
Types apply to objects and constants.

 

[Hallvard B Furuseth]

N869
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not
designate an object when it is evaluated, the behavior is
undefined.

Therefore, the evaluation of any integer constant,
yields undefined behavior, in C99,
except that the standard can't possibley mean what it says there.

...unless it means that constants are objects.

ITYM ...unless it means that constants are objects and lvalues.

Do you think that consants are lvalues ?

Oh. Yes. A constant is an expression, at least once you put it in a
program, and it has object type. So it fits the above description.

Everything seems to be lvalues in standard C. I don't know what the
term 'lvalue' is good for anymore.

 

[Hallvard B Furuseth]

But in 6.3.2.1 the standard /explicitly/ states that
evaluating lvalues that do not designate objects (integer
constants being one example) invokes UB, which is Standardese
for: "Don't do it!"

I think integer constants are objects, and that what this text refers
to is lvalues like *p where p points to freed memory. That freed
memory is no longer an object.

 

[Hallvard B Furuseth]

I think it falls down to the fact the standard does not say to
much explicitly, but rather on how it uses the term.

Me and Joe Wright had a discussion about this some time back.

If you want to see the arguments made then Message id of starting post
is: <[email protected]>

Thanks.

I'm wondering about one thing: Why single out pointers, and the `&'
operator? Do you also think that the result of expressions like `a + b'
are not objects, or is there something special about &?

 

[pete]

Hallvard B Furuseth wrote:

Everything seems to be lvalues in standard C. I don't know what the
term 'lvalue' is good for anymore.

My understanding of lvalues and objects is from C89.
If you want to talk C99,
then I just don't know about those things anymore.

 

[Peter Pichler]

I'm wondering about one thing: Why single out pointers, and the `&'
operator? Do you also think that the result of expressions like `a + b'
are not objects, or is there something special about &?

The thread started with a question about a difference between objects and
pointers and drifted off into a discussion whether all pointers are objets
or not.

 

[Joe Wright]

[ snip ]

I think integer constants are objects, and that what this text refers
to is lvalues like *p where p points to freed memory. That freed
memory is no longer an object.

From K&R2 A4 p195
"An object, sometimes called a variable, is a location in storage, and
its interpretation depends on two main attributes: its 'storage class'
and its 'type'."..

That doesn't sound like a constant to me. I must have missed something
important earlier. Give me an example of an integer constant that you
think is an object. Please.

 

[Joe Wright]

Thanks.

I'm wondering about one thing: Why single out pointers, and the `&'
operator? Do you also think that the result of expressions like `a + b'
are not objects, or is there something special about &?

Assuming..

int a = 4;
int b = 5;
int c;

c = a + b;

The variables a, b and c are objects. The value of a is 4. The value of
b is 5. The value of a + b is 9. But 9 is not an object, c is.

 

[E. Robert Tisdale]

int a = 4;
int b = 5;
int c;

It is a bad idea to leave a variable undefined.

c = a + b;

It would be better to write:

int a = 4;
int b = 5
int c = a + b;

Or better yet:

const int a = 4; // description of a
const int b = 5; // description of b
const int c = a + b; // description of c

since there is no indication that you need variables
in this context.

 

[Joe Wright]

It is a bad idea to leave a variable undefined.


It would be better to write:

int a = 4;
int b = 5
int c = a + b;

Or better yet:

const int a = 4; // description of a
const int b = 5; // description of b
const int c = a + b; // description of c

since there is no indication that you need variables
in this context.

Hi Bob. Thanks for joining. I can't tell you how much I appreciate your
critique. Really, I can't. You don't know what you're talking about and
you don't know what I'm talking about. Is a + b an object?