Xref: utzoo comp.sys.mips:1293 comp.std.c:4156
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!ucbvax!bloom-beacon!deccrl!news.crl.dec.com!shlump.nac.dec.com!tkou02.enet.dec.com!jit345!diamond
From: diamond@jit345.swstokyo.dec.com (Norman Diamond)
Newsgroups: comp.sys.mips,comp.std.c
Subject: Re: compiler bug
Keywords: structures, addressable
Message-ID: <1991Jan23.031214.544@tkou02.enet.dec.com>
Date: 23 Jan 91 03:12:14 GMT
References: <1685@svin02.info.win.tue.nl>
Sender: news@tkou02.enet.dec.com (USENET News System)
Reply-To: diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond)
Followup-To: comp.sys.mips,comp.std.c
Organization: Digital Equipment Corporation Japan , Tokyo
Lines: 27

In article <1685@svin02.info.win.tue.nl> debra@svin02.info.win.tue.nl (Paul de Bra) writes:

>struct a { int b, int c } d , e ;
      should be  ;
>main()
>{
>  int f;
>  f = (d=e).b;
>}

After correcting your bug, I saw the same error message that you saw.
Actually it's inherited from BSD's pcc, which is probably inherited
from System III's pcc (because the last time I touched a System V
machine, its pcc-based compiler accepted this usage of ".").

In ANSI C, (d=e) is a perfectly legal non-lvalue value, therefore (d=e).b
is also a perfectly legal non-lvalue value.  (I would say rvalue but ANSI C
doesn't use this word, except for a dangling reference in the index.)

(d=e),d.b  also yields a perfectly legal non-lvalue value, so I would
agree with your suggestion that it should be equivalent.

In K&R-I, the left operand of "." had to be an lvalue.  Therefore, if your
vendor does not claim ANSI conformance, it might not be a compiler bug.
--
Norman Diamond       diamond@tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.