Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!princeton!allegra!alice!dmr
From: dmr@alice.UUCP
Newsgroups: comp.lang.c
Subject: lvalues
Message-ID: <6539@alice.uUCp>
Date: Fri, 16-Jan-87 01:27:09 EST
Article-I.D.: alice.6539
Posted: Fri Jan 16 01:27:09 1987
Date-Received: Mon, 19-Jan-87 23:58:26 EST
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 37

The question of lvalues has arisen recently both in the context
of the silly C book review, and also in relation to the operand
of ++.  The term is old (it comes from BCPL or earlier) and
just denotes the things that can appear on the left (`l') of
an assignment.

The White Book and the current ANSI draft both waffle about whether
the term is formal or descriptive; they introduce it by, respectively,
"an expression referring to an object [which is a] manipulatable
region of storage;" and "an expression that designates an object."

It might cause less confusion if the definition were explicitly syntactic,
and only certain lvalues were permitted by the semantics to be
assigned to.  In this scheme, an lvalue (eliding precedence) is defined
as one of

	identifier
	( lvalue )
	lvalue . identifier
	* expression

Also, by applying equivalence rules,

	expression[expression]     =>    *(expression + expression)
	expression->identifier     =>    (*expression).identifier

Only some lvalues can appear on the left of `=' (e.g.: not array,
not const, not function).  Even more restrictions apply to operands
of `&': not register, not bit-field.

This suggestion doesn't change the language, but it makes it
clearer what an lvalue actually is.  Both the old and new
reference manuals make it hard for the reader to enumerate the possible
lvalues.

		Dennis Ritchie
		research!dmr