Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior
Message-ID: <12291@dog.ee.lbl.gov>
Date: 19 Apr 91 19:33:20 GMT
References: <1991Apr6.091013.26131@daffy.cs.wisc.edu> <690004@hplvec.LVLD.HP.COM> <1991Apr19.172024.10364@cbnewsj.att.com>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 25
X-Local-Date: Fri, 19 Apr 91 12:33:20 PDT

[  (unsigned int)(*((unsigned int *)0xffff8e20L)) = 0x03;  ]

In article <1991Apr19.172024.10364@cbnewsj.att.com> asd@cbnewsj.att.com
(Adam S. Denton) writes:
>This debate is apparently what assigning to a casted expression should do.

Actually, the original debate ignored the illegal source and concentrated
on the questionable (depends-on-sign-extension) object code.

The above is very clearly
>    (cast) [something] = [some value];
>which has never been defined to have any meaning whatsoever.

Actually, it is defined far enough to require a diagnostic from an ANSI
conformant compiler (after which all bets are off).  (This is another
example I would not expect to find in a book on `how to use ANSI C',
and illustrates why such a book is not good for `knowing the ANSI
standard'.  It is also an example of why `knowing the standard' is
often unnecessary: it suffices to know `the result of a cast is a
value, not an object, and may not be modified' without knowing just
what is required of, and allowed of, a compiler when it is handed such
an expression.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov