gcc: pointer to array

[Tim Rentsch]

Definition:

ISO 1087:1990:
Statement which describes a concept and permits its differentiation
from other concepts within a system of concepts.

ISO 1087-1:2000:
Representation of a concept by a descriptive statement which serves to
differentiate it from related concepts.

To see that the definition for lvalue:

An lvalue is an expression with an object type
or an incomplete type other than void;

is bad, simply consider the question, "Does this statement allow
differentiation of this concept from other (related) concepts?"
Obviously it does not.

 

[Simon Biber]

So as far as ISO 1087 is concerned, a "definition" distinguishes the
defined term from other terms, but doesn't necessarily distinguish
things that meet the definition from things that don't.

This reflects a different kind of definition -- the sort that you would
expect in a dictionary, versus the sort that you would expect in the C
standard.

Nobody expects the definitions in general-purpose dictionary to provide
an absolutely accurate treatise on what can be considered a "flower" and
what cannot, let alone more abstract concepts like "love". A reasonable
description of the concept, that allows you to tell it apart from other
similar concepts, is enough.

On the other hand, the C Standard is expected to be used to create a
family of computer programs, called "implementations", which can all
accept exactly the same input and (produce programs that) have exactly
the same behaviour. The Standard is expected to be the final arbiter of
whether an implementation is correct or incorrect. For this reason, any
definitions in the Standard should be held to a higher standard.

 

[lawrence.jones]

Nobody expects the definitions in general-purpose dictionary to provide
an absolutely accurate treatise on what can be considered a "flower" and
what cannot, let alone more abstract concepts like "love". A reasonable
description of the concept, that allows you to tell it apart from other
similar concepts, is enough.

On the other hand, the C Standard is expected to be used to create a
family of computer programs, called "implementations", which can all
accept exactly the same input and (produce programs that) have exactly
the same behaviour. The Standard is expected to be the final arbiter of
whether an implementation is correct or incorrect. For this reason, any
definitions in the Standard should be held to a higher standard.

I disagree. The *definitions* in the standard, like the definitions in
a dictionary, are just intended to be reasonable descriptions of the
concepts. The rest of the standard is the accurate treatise describing
them in detail.

-Larry Jones

In a minute, you and I are going to settle this out of doors. -- Calvin

 

[Keith Thompson]

I disagree. The *definitions* in the standard, like the definitions in
a dictionary, are just intended to be reasonable descriptions of the
concepts. The rest of the standard is the accurate treatise describing
them in detail.

In my opinion, the C99 standard's definition of "lvalue" fails even by
that criterion. If I had never heard of an "lvalue", reading the
definition in C99 6.3.2.1p1 would not give me a good idea of what it's
supposed to be. The core of what an lvalue is all about is that it
(at least potentially) designates an object. The C90 definition
captured this idea; the C99 definition does not.

 

[Dik T. Winter]

Badly worded, I think.

Idem.

> To see that the definition for lvalue:
> An lvalue is an expression with an object type
> or an incomplete type other than void;
> is bad, simply consider the question, "Does this statement allow
> differentiation of this concept from other (related) concepts?"
> Obviously it does not.

It does distinguish an lvalue from a non-lvalue. And that is one of
the reasons I think the 1087 definitions are bad. In general the
only related concept from which a definition distinguishes a particular
concept, is the negation of that particular concept. In mathematics
almost all definitions are like this. (An infinite set is blah-blah.
This only distinguishes the infinite sets from the non-infinite, or
finite, sets.)

 

[Tim Rentsch]

Badly worded, I think.


It does distinguish an lvalue from a non-lvalue.

It's hard to consider this response as serious. Obviously the given
definition serves to differentiate the concept of "lvalue" from the
concepts of kumquat, electromagnetic field, or prime numbers. Clearly
though the statements in ISO 1087 are meant to imply that a definition
should allow differentiation from all (distinct) related concepts, not
just from some of them.

And that is one of
the reasons I think the 1087 definitions are bad. In general the
only related concept from which a definition distinguishes a particular
concept, is the negation of that particular concept. In mathematics
almost all definitions are like this. (An infinite set is blah-blah.
This only distinguishes the infinite sets from the non-infinite, or
finite, sets.)

The definition of a group clearly distinguishes it from the concept of
a field. Are groups and fields related concepts? I think most
mathematicians would say yes. Probably more to the point, any set of
concepts discussed in a single ISO document are related concepts, if
for no other reason than that they all pertain to the topic the
document addresses.

I agree that the definition of the term "definition" is 1087 can and
should be improved. But the definition of "lvalue" fails even the
weak test provided by 1087. In particular, the definition of the term
"lvalue" does not allow <the concept of lvalue> to be differentiated
from <the concept of an expression with an object type or an incomplete
type other than void>. (It isn't necessary to give a concept a name
for the concept to exist.) Since these two concepts are *supposed*
to be distinct, the definition should allow them to be differentiated
rather than saying that they are the same.

 

[Dik T. Winter]

>
> It's hard to consider this response as serious.

It *was* serious.

>
> The definition of a group clearly distinguishes it from the concept of
> a field. Are groups and fields related concepts?

Yes, they are related. So much so that every field is also a group (a field
is an additive group with quite a bit more structure). So the definition of
a group should not clearly distinguish it from the concept of a field.
To get an analogue you might say that the definition of field (a field is
a commutative ring where each element has a multiplicative inverse),
distinguishes fields from rings that are not fields.

> In particular, the definition of the term
> "lvalue" does not allow <the concept of lvalue> to be differentiated
> from <the concept of an expression with an object type or an incomplete
> type other than void>. (It isn't necessary to give a concept a name
> for the concept to exist.) Since these two concepts are *supposed*
> to be distinct, the definition should allow them to be differentiated
> rather than saying that they are the same.

Why do you think those two concepts are supposed to be different? I
would rather think (given the definition) that they are supposed to
be the same.

 

[Keith Thompson]

Why do you think those two concepts are supposed to be different? I
would rather think (given the definition) that they are supposed to
be the same.

Given the definition, they are the same. That's the problem.

The integer constant 42 is <an expression with an object type or an
incomplete type other than void>. It is not intended to be an lvalue.
A good definition of lvalue would tell us that 42 is not an lvalue;
the current on doesn't.

 

[Tim Rentsch]

It *was* serious.

Yes, I see that. Maybe I should have said "I don't see what
point you're trying to make". Having seen no small number of
articles written by Dik Winter, and finding them much more often
than not to be relevant and offer some level of insight, I found
the comments in the lvalues/definitions posting rather baffling.
Anyway, no matter.

[snip]

In particular, the definition of the term
"lvalue" does not allow <the concept of lvalue> to be differentiated
from <the concept of an expression with an object type or an incomplete
type other than void>. (It isn't necessary to give a concept a name
for the concept to exist.) Since these two concepts are *supposed*
to be distinct, the definition should allow them to be differentiated
rather than saying that they are the same.

Why do you think those two concepts are supposed to be different? I
would rather think (given the definition) that they are supposed to
be the same.

That's sort of where this subthread started. The definition of
lvalue (given in 6.3.2.1 p1) says that an lvalue is (defined to
be) an expression with an object type or an incomplete type
other than void; whereas, as many or most regular readers of
CLC know, an lvalue is *supposed* to be something else (roughly
speaking, an expression that forms an address, which address
needs to be implicitly dereferenced to get a value, or which in
certain cases may be used to store a value into an object at
that address).

Why do people (including myself) think this? Various statements
in sections 6.5.x that certain kinds of expressions -- but not
all expressions with object type -- are lvalues; and, footnotes
here and there that other kinds of expressions (still with
object type) are not lvalues. Other related comments also; for
example, in talking about the address-of operator, 6.5.3.2 says
the operand of '&' shall be (other unrelated stuff or) an
lvalue (that isn't a register or referring to a bit-field).
Clearly this restriction isn't meant to allow all expressions
of object type: the expression

&(a+b)

is nonsense.

 

[Joe Wright]

[...]

In particular, the definition of the term
"lvalue" does not allow <the concept of lvalue> to be differentiated
from <the concept of an expression with an object type or an incomplete
type other than void>. (It isn't necessary to give a concept a name
for the concept to exist.) Since these two concepts are *supposed*
to be distinct, the definition should allow them to be differentiated
rather than saying that they are the same.

Why do you think those two concepts are supposed to be different? I
would rather think (given the definition) that they are supposed to
be the same.

Given the definition, they are the same. That's the problem.

The integer constant 42 is <an expression with an object type or an
incomplete type other than void>. It is not intended to be an lvalue.
A good definition of lvalue would tell us that 42 is not an lvalue;
the current on doesn't.

I see 42 as an expression of a value with int type. given ..
int a;
a = 42;
... the expression a is the int typed object (an lvalue) and 42 is the
int typed value. It is absurd to suggest that a value with int type is
an object.

That 42 has int type does not say (to me) that it has object type.

The line forms over here..

 

[Keith Thompson]

I see 42 as an expression of a value with int type. given ..
int a;
a = 42;
.. the expression a is the int typed object (an lvalue) and 42 is the
int typed value. It is absurd to suggest that a value with int type is
an object.

That 42 has int type does not say (to me) that it has object type.

The line forms over here..

A value with int type is not necessarily an object, but int is
definitely an object type. C99 6.2.5 says:

Types are partitioned into _object types_ (types that fully
describe objects), _function types_ (types that describe
functions), and _incomplete types_ (types that describe objects
but lack information needed to determine their sizes).

Since int is a type, and it's neither a function type nor an
incomplete type, it ust be an object type.

 

[Joe Wright]

[...]


In particular, the definition of the term
"lvalue" does not allow <the concept of lvalue> to be differentiated
from <the concept of an expression with an object type or an incomplete
type other than void>. (It isn't necessary to give a concept a name
for the concept to exist.) Since these two concepts are *supposed*
to be distinct, the definition should allow them to be differentiated
rather than saying that they are the same.

Why do you think those two concepts are supposed to be different? I
would rather think (given the definition) that they are supposed to
be the same.

Given the definition, they are the same. That's the problem.
The integer constant 42 is <an expression with an object type or an
incomplete type other than void>. It is not intended to be an lvalue.
A good definition of lvalue would tell us that 42 is not an lvalue;
the current on doesn't.

I see 42 as an expression of a value with int type. given ..
int a;
a = 42;
.. the expression a is the int typed object (an lvalue) and 42 is the
int typed value. It is absurd to suggest that a value with int type is
an object.

That 42 has int type does not say (to me) that it has object type.

The line forms over here..

A value with int type is not necessarily an object, but int is
definitely an object type. C99 6.2.5 says:

Types are partitioned into _object types_ (types that fully
describe objects), _function types_ (types that describe
functions), and _incomplete types_ (types that describe objects
but lack information needed to determine their sizes).

Since int is a type, and it's neither a function type nor an
incomplete type, it ust be an object type.

You clearly (tentatively?) agree with me. Thanks. But you say "A value
with int type is not necessarily an object..". I contend that a value is
never an object. Objects are so construed so as to contain values.

Much of our discourse here in c.l.c is to interpret the meaning of the
scribes of C99 with the inferrence that the scribes are somehow inspired
and therfore infallible. Utter nonsense to me.

It is the gospel according to DMR as described by BWK which sustains and
empowers me up to and including C89.

Who needs or even wants C99?

 

[Keith Thompson]

Keith Thompson wrote:



[...]


In particular, the definition of the term
"lvalue" does not allow <the concept of lvalue> to be differentiated
from <the concept of an expression with an object type or an incomplete
type other than void>. (It isn't necessary to give a concept a name
for the concept to exist.) Since these two concepts are *supposed*
to be distinct, the definition should allow them to be differentiated
rather than saying that they are the same.

Why do you think those two concepts are supposed to be different? I
would rather think (given the definition) that they are supposed to
be the same.

Given the definition, they are the same. That's the problem.
The integer constant 42 is <an expression with an object type or an
incomplete type other than void>. It is not intended to be an lvalue.
A good definition of lvalue would tell us that 42 is not an lvalue;
the current on doesn't.


I see 42 as an expression of a value with int type. given ..
int a;
a = 42;
.. the expression a is the int typed object (an lvalue) and 42 is the
int typed value. It is absurd to suggest that a value with int type is
an object.

That 42 has int type does not say (to me) that it has object type.

The line forms over here..

A value with int type is not necessarily an object, but int is
definitely an object type. C99 6.2.5 says:
Types are partitioned into _object types_ (types that fully
describe objects), _function types_ (types that describe
functions), and _incomplete types_ (types that describe objects
but lack information needed to determine their sizes).
Since int is a type, and it's neither a function type nor an
incomplete type, it ust be an object type.

You clearly (tentatively?) agree with me. Thanks. But you say "A value
with int type is not necessarily an object..". I contend that a value
is never an object. Objects are so construed so as to contain values.

Right, values and objects are two distinct things, and a value is
never an object. My "not necessarily" wasn't intended to exclude
that; I just didn't take the time to think it through, and the point
wasn't particularly relevant.

But I don't see how you conclude that I agree with you. You wrote
(see above):

That 42 has int type does not say (to me) that it has object type.

I unequivocally disagreed with that statement. The fact that 42 has
int type means that it *does* have object type.

Just what did you think I was agreeing with?

 

[Dik T. Winter]

>
> That's sort of where this subthread started.

Yes, I see now what your problem is (at least, according to my draft standard).
Let's have a look at the definition:

That it does not distinguish from related concepts is irrelevant (in most
of mathematics and computer science a definition just gives a name to some
concept with, hopefully, means to determine whether something falls under
the definition or not).

But there is a sentence following it:
"if an lvalue does not designate an object when it is evaluated, the
behavior is undefined."
So, while the constant 42 is of an object type, it is not an object, and
any use as an lvalue will result in undefined behaviour.

Back to your comments:

> The definition of
> lvalue (given in 6.3.2.1 p1) says that an lvalue is (defined to
> be) an expression with an object type or an incomplete type
> other than void; whereas, as many or most regular readers of
> CLC know, an lvalue is *supposed* to be something else (roughly
> speaking, an expression that forms an address, which address
> needs to be implicitly dereferenced to get a value, or which in
> certain cases may be used to store a value into an object at
> that address).

I do not know whether this comment is indeed true. I am not going to
read the complete standard now. But *when* an lvalue that is not an
object type is evaluated, the result is UB. Which means that an
evaluatable lvalue is precisely what you describe. (I do not know
off-hand under what circumstances an lvalue is not evaluated.)

> Why do people (including myself) think this? Various statements
> in sections 6.5.x that certain kinds of expressions -- but not
> all expressions with object type -- are lvalues;

Pray provide a reference. I have looked through the draft and did
not find any such statements.

> and, footnotes
> here and there that other kinds of expressions (still with
> object type) are not lvalues.

Again, pray provide references.

> Other related comments also; for
> example, in talking about the address-of operator, 6.5.3.2 says
> the operand of '&' shall be (other unrelated stuff or) an
> lvalue (that isn't a register or referring to a bit-field).
> Clearly this restriction isn't meant to allow all expressions
> of object type: the expression
> &(a+b)
> is nonsense.

Depends on the types of a and b. But when they are (say) integer
variables, the expression is indeed an lvalue. But the address
operator requires evaluation, and there you are. UB, because there
is not an object.

 

[Dik T. Winter]

Why do you think so?

But it *is* an lvalue. However, any use of it *as* an lvalue will result
in undefined behaviour. So you may write:
&42
without problems (there is neither a syntactic error, nor a semantic error),
but that use is undefined behaviour. So it can do anything. There might
even be conforming implementations that, when giving the following programme:
#include <stdio.h>
int main(void) {
&42 = 5;
printf("%d\n", 42);
}
will happily give 5 as output.

 

[Keith Thompson]

Yes, I see now what your problem is (at least, according to my draft
standard). Let's have a look at the definition:


That it does not distinguish from related concepts is irrelevant (in most
of mathematics and computer science a definition just gives a name to some
concept with, hopefully, means to determine whether something falls under
the definition or not).

But there is a sentence following it:
"if an lvalue does not designate an object when it is evaluated, the
behavior is undefined."
So, while the constant 42 is of an object type, it is not an object, and
any use as an lvalue will result in undefined behaviour.

You say "any use *as an lvalue*". The standard says the behavior is
undefined *when it is evaluated*; it doesn't say "as an lvalue".

An lvalue is a kind of expression (all lvalues are expressions; not all
expressions are lvalues). If 42 is an lvalue, then it is evaluated in

int x;
x = 42;

and a literal reading of the standard implies that this evaluation
invokes undefined behavior.

The intent is that 42 is not an lvalue (though it is an expression
with an object type), and that evaluating it does not invoke undefined
behavior.

Back to your comments:

I do not know whether this comment is indeed true. I am not going to
read the complete standard now. But *when* an lvalue that is not an
object type is evaluated, the result is UB.

Was this a typo?

An lvalue is always of an object type, both by definition and by
intent. UB is invoked when an lvalue that doesn't designate an object
is evaluated. (Being of an object type and designating an object are
two very different things.)

Which means that an
evaluatable lvalue is precisely what you describe. (I do not know
off-hand under what circumstances an lvalue is not evaluated.)

When it's the operand of sizeof (unless it designates a VLA). When
it's the right operand of an "&&" operator whose left operand is zero.
When it appears in a function that isn't called. And so forth.

Pray provide a reference. I have looked through the draft and did
not find any such statements.

For example, 6.5.16p3:

An assignment operator stores a value in the object designated by
the left operand. An assignment expression has the value of the
left operand after the assignment, but is not an lvalue.

Again, pray provide references.

6.5.2.5, footnote 80, says the result of a cast expression is not
an lvalue.

6.5.4, footnote 85, says that a cast does not yield an lvalue.

Etc.

Depends on the types of a and b. But when they are (say) integer
variables, the expression is indeed an lvalue. But the address
operator requires evaluation, and there you are. UB, because there
is not an object.

No, it's a constraint violation (and no, it doesn't depend on the
types of the operands).

6.5.3.2p1 says that the operand of the unary & operator shall be
"... or an lvalue that designates an object that is ...". (The stuff
I've left out refers to function designators, bit fields, register
variables, and so forth, none of which is relevant here.) Given the
*intended* meaning of "lvalue", a+b is not an lvalue, so &(a+b)
violates a constraint. It doesn't merely invoke undefined behavior.

The statement that evaluating an lvalue that doesn't designate an
object invokes UB was intended to cover things like this:

int *ptr = NULL;
int i = *ptr;

*ptr is an lvalue, but it doesn't designate an object when it's
evaluated, so the evaluation invokes undefined behavior.

&(a+b) is no more or less sensible than x+3=42 or 1=2 (those are C
assignments, not mathematical comparisons). All are constraint
violations.

The only real problem is that this isn't as clear as it should be
because the definition of "lvalue" is broken.

 

[Keith Thompson]

Why do you think so?[/QUOTE]

See footnote 53 in C99 6.3.2.1:

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

An obvious example of an lvalue is an identifier of an object. As
a further example, if E is a unary expression that is a pointer to
an object, *E is an lvalue that designates the object to which E
points.

42 is not an "object locator value"; there is no object associated
with it.

The C90 standard's definition of lvalue is:

An _lvalue_ is an expression (with an object type or an incomplete
type other than void) that designates an object.

42 is obviously not an lvalue under this definition. But the C90
definition is flawed; it implies that the name of a pointer object is
an lvalue if and only if it designates an object, which can be
determined only at execution time. The C99 definition was intended to
keep the same intended meaning while resolving this flaw;
unfortunately, it dropped the idea of designating an object, which is
what an lvalue is all about.

The C99 Rationale, in section 6.3.2.1, says:

A difference of opinion within the C community centered around the
meaning of _lvalue_, one group considering an lvalue to be any
kind of object locator, another group holding that an lvalue is
meaningful on the left side of an assigning operator. The C89
Committee adopted the definition of lvalue as an object
locator. The term _modifiable lvalue_ is used for the second of
the above concepts.

But it *is* an lvalue.

[...]

Only if you read the C99 standard's definition of "lvalue" literally.

 

[Richard Bos]

But it *is* an lvalue. However, any use of it *as* an lvalue will result
in undefined behaviour.

Quite. Which is clearly the wrong thing. Currently, thanks to C99,
correct, but still Wrong.

Richard

 

[Tim Rentsch]

[snip]
But there is a sentence following it:
"if an lvalue does not designate an object when it is evaluated, the
behavior is undefined."
So, while the constant 42 is of an object type, it is not an object, and
any use as an lvalue will result in undefined behaviour.[/QUOTE]

What I think you mean to say is: according to how lvalue is
defined in the standard, any evaluation of 42 (because it is
an lvalue and does not designate an object) will result in
undefined behavior.

Clearly an evaluation of an integer constant isn't supposed to
cause undefined behavior.

Back to your comments:

I do not know whether this comment is indeed true. I am not going to
read the complete standard now. But *when* an lvalue that is not an
object type is evaluated, the result is UB.

Are you confusing the two concepts? Having object type is a
static property of expressions; whether the result of an
evaluation designates an object is a run-time property of the
value of an expression's evaluation. Almost all expressions
that are lvalues have object type; the exceptions are things
like array names of unknown length and a few other things that
people hardly ever write in actual programs.

Which means that an evaluatable lvalue is precisely
what you describe. [snip]

First let me distinguish two terms. An lvalue(S) is an
lvalue as it is defined in the standard. An lvalue(U) is
an lvalue as understood by most CLC regulars and by all
the implementations I'm familiar with.

Using that terminology, what you're saying is that I'm
describing an evaluatable lvalue(S).

My intention was to describe an lvalue(U); whether that
corresponds to an evaluatable lvalue(S) depends on what's
meant by "evaluatable". There is nothing in my description of
lvalue(U) that says the address will actually designate an
object; eg, '* (char*) 0' is an lvalue(U), but it does not
designate an object.

Not counting that minor point though I think your point is
correct: an lvalue(U) corresponds to an lvalue(S) for which
evaluation is plausible.

Why do people (including myself) think this? Various statements
in sections 6.5.x that certain kinds of expressions -- but not
all expressions with object type -- are lvalues;

Pray provide a reference. I have looked through the draft and did
not find any such statements. [...also for footnotes...]

The index for "lvalue" shows 6.5.1, 6.5.2.4, 6.5.3.1, and
6.5.16. The footnotes include numbers 95, 92 and 94; I
believe these numbers correspond to numbers 76, 83 and 85 in
N869. I'm pretty sure this list isn't complete; I haven't
attempted to do any kind of exhaustive search.

Depends on the types of a and b.

Actually I think the expression '&(a+b)' is nonsense no matter
what the types of a and b are.

But when they are (say) integer
variables, the expression is indeed an lvalue.

The expression '(a+b)' is an lvalue(S). It is not an
lvalue(U).

But the address
operator requires evaluation, and there you are. UB, because there
is not an object.

Consider this expression:

sizeof &(a+b)

Assuming no variable length arrays, there is no evaluation of
the address operator; however, the expression is still
illegal:


$ cat lvalue.c
void
foo(){
int a, b;
sizeof &(a+b);
}

$ gcc -ansi -pedantic lvalue.c
lvalue.c: In function `foo':
lvalue.c:4: invalid lvalue in unary `&'

$ gcc -std=c99 -pedantic lvalue.c
lvalue.c: In function `foo':
lvalue.c:4: invalid lvalue in unary `&'

 

[Netocrat]

"Dik T. Winter" <[email protected]> writes:

You say "any use *as an lvalue*". The standard says the behavior is
undefined *when it is evaluated*; it doesn't say "as an lvalue".

An lvalue is a kind of expression (all lvalues are expressions; not all
expressions are lvalues). If 42 is an lvalue, then it is evaluated in

int x;
x = 42;

and a literal reading of the standard implies that this evaluation
invokes undefined behavior.

I hadn't noticed that before but you're right.

It is possible to argue that since the concept of lvalue is so broadly
defined, the standard must specify separately for each expression
whether it is an lvalue or not, and by that reasoning whether or not a
constant is an lvalue would be unspecified. I prefer your reasoning
though since it "catches" unspecified expressions (albeit detrimentally
in this case).

I've put together a comprehensive list by searching for the string
"lvalue" in N869, starting at the beginning and stopping at the
annexes. I posted it recently in a separate thread but obviously you
didn't see that post.

lvalues:
6.5.1#2 an identifier declared as designating an object
6.5.1#4 a string literal
6.5.1#5 a parenthesized expr if the unparenthezised expr is an lvalue
6.5.2.3#3 struct expression members accessed with "." if the struct
expression is an lvalue
6.5.2.3#4 struct expression members accessed with "->"
6.5.2.5#5 a compound literal
6.5.3.2#4 the result of "*" if the operand points to an object
7.5#2 errno

non-lvalues:
6.5.3.2#3 the result of "&*"
6.5.16#3 an assignment expression
Non-normative footnotes: cast, comma and conditional expressions

The footnotes are 76, 83 and 85 in the draft I use:
http://dev.unicals.com/papers/c99-draft.html

Also I've updated and rewritten my summary of "the lvalue situation"
which includes the above list and is mostly a distillation of the
relevant parts of this thread. You may find it easier to process than
rereading this scattered and messy thread:
http://members.dodo.com.au/~netocrat/c/lvalue.html

<snip rest of Keith's reply, which I endorse>