Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.c
Subject: Re: &&**
Message-ID: <23314:Sep1122:28:1390@kramden.acf.nyu.edu>
Date: 11 Sep 90 22:28:13 GMT
References: <0926@sheol.UUCP> <20757:Sep1115:30:0390@kramden.acf.nyu.edu> <853.26ed0446@iccgcc.decnet.ab.com>
Distribution: usa
Organization: IR
Lines: 25

In article <853.26ed0446@iccgcc.decnet.ab.com> browns@iccgcc.decnet.ab.com (Stan Brown, Oak Road Systems) writes:
> In article <20757:Sep1115:30:0390@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> > Question for the standards people: Is && undefined, unspecified,
> > implementation-defined, or what have you? 
> See page 49 of K&R 1, or page 53 of K&R 2.

K&R1 is obviously an incorrect answer, as I was wondering exactly what
level of error-ness &(&(...)) has under ANSI. I don't have K&R2 (does it
really indicate specific error levels?) or the standard, which is why I
was asking in the first place.

I can believe that it's simply erroneous, as it's easy enough for the
compiler to detect. In that case compilers that accept it really are
broken. But is that what the standard settled on?

This is an extremely important question, by the way, as several
implementations would apparently be in violation of conformance if &&
isn't just undefined. They'd be misusing the ``ANSI C'' trademark, and
probably be guilty of false advertising, and maybe even tax evasion.
Remember, this is the very first hint that a compiler might not be
perfectly designed and programmed, or that the implementors might be so
ridiculously incompetent that their programs actually show a b-b-b-bug.
*Extremely* important. *Extremely* incompetent. (Okay, Dan, cut...)

---Dan