Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!cs.utexas.edu!samsung!xylogics!merk!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: &&**
Summary: Definitely illegal
Message-ID: <17959@haddock.ima.isc.com>
Date: 11 Sep 90 20:56:04 GMT
References: <1990Sep7.021321.18381@watmath.waterloo.edu> <1990Sep7.080855.24070@irisa.fr> <0926@sheol.UUCP> <20757:Sep1115:30:0390@kramden.acf.nyu.edu>
Reply-To: karl@kelp.ima.isc.com (Karl Heuer)
Distribution: usa
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 16

In article <20757:Sep1115:30:0390@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <0926@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:
>  [ that if a compiler reduces &&**x to x then it is buggy ]
>
>Question for the standards people: Is && undefined, unspecified,
>implementation-defined, or what have you?

Applying "&" to an operand that is neither a function designator nor an lvalue
violates a constraint (3.3.3.2).  Therefore, a conforming implementation is
required to diagnose an error.

(As with all such diagnostics, it is permissible for it to be a mere warning;
the implementation need not abort the compilation if it chooses to support the
extension that "&*x" is an lvalue.)

Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint