[comp.std.c] compiler bug

diamond@jit345.swstokyo.dec.com (Norman Diamond) (01/23/91)

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.

gwyn@smoke.brl.mil (Doug Gwyn) (01/24/91)

In article <1991Jan23.031214.544@tkou02.enet.dec.com> diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond) writes:
>(I would say rvalue but ANSI C
>doesn't use this word, except for a dangling reference in the index.)

It's not a dangling reference; "rvalue" is mentioned in a footnote.

rogerk@mips.COM (Roger B.A. Klorese) (01/24/91)

In article <1991Jan23.031214.544@tkou02.enet.dec.com> diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond) writes:
>In ANSI C, (d=e) is a perfectly legal non-lvalue value, therefore (d=e).b
>is also a perfectly legal non-lvalue value.
>(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.

And, of course, MIPS-C claims K&R-I compliance only.  This reference is
accepted in the new ANSI C compiler which is in beta test.  (Sorry, we
have a full complement of test sites, and are not accepting any more.)
It is accepted in the K&R mode of the 2.20 compilers as well, as of now;
we will check if this should be rejected.
-- 
ROGER B.A. KLORESE                                  MIPS Computer Systems, Inc.
MS 6-05    930 DeGuigne Dr.   Sunnyvale, CA  94086              +1 408 524-7421
rogerk@mips.COM         {ames,decwrl,pyramid}!mips!rogerk         "I'm the NLA"
"WAR: been there, done that... hated it."  -- QueerPeace/DAGGER chant