Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site boulder.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!seismo!hao!cires!boulder!gibbons
From: gibbons@boulder.UUCP (Doug Gibbons)
Newsgroups: net.lang.c
Subject: Does & return an lvalue?
Message-ID: <165@boulder.UUCP>
Date: Sat, 7-Apr-84 10:13:08 EST
Article-I.D.: boulder.165
Posted: Sat Apr  7 10:13:08 1984
Date-Received: Mon, 9-Apr-84 05:37:02 EST
Organization: University of Colorado, Boulder
Lines: 24

Earlier this week I asked the net if

main()
{
	int *i, *j;
	&(*i) = j;
}

was a valid program. I was not concerned about whether or not it
compiles (depends upon your compiler). I was mainly interested here
in why anyone should think that "&*i" is an lvalue. Section
7.2 of K&R discusses both unary * and unary &. While from the description
of * it is quite obvious that *&E == E (in fact the draft standard explicitly
guarantees it), it is not at all obvious that &*E == E. Unary * will always
return an lvalue, but & is undefined in this respect. Although the above
program will compile on some implementations, I suspect that one that
will compile it is PCC based. The reason can be found in "A Tour of the
Portable C Compiler" by S.C. Johnson. In this document, we are told that
the compiler will always treat adjacent *& and &* as an identity operators.
Either the implementers were reading something into the langauge spec that
is not there, or they were taking a stand on handling an ill-defined
situation. In either case, the X3J11 ANSI should be told about this and
clean it up.