Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!ulysses!allegra!mit-eddie!husc6!cmcl2!nrl-cmf!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!eagle!icdoc!cam-cl!am
From: am@cam-cl.UUCP
Newsgroups: comp.lang.c
Subject: Re: what C needs
Message-ID: <1128@jenny.cl.cam.ac.uk>
Date: 15 Jan 88 15:30:40 GMT
References: <8712241909.AA03710@decwrl.dec.com> <6926@brl-smoke.ARPA> <496@doug.UUCP> <6995@brl-smoke.ARPA>
Reply-To: am@cl.cam.ac.uk (Alan Mycroft)
Organization: U of Cambridge Comp Lab, UK
Lines: 29
Posted: Fri Jan 15 10:30:40 1988

In article <6995@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
[re holes in structures, when passed by value]
>>Is the extra byte copied along, or is it filled with new-and-improved
>>undefined garbage?
>
>I don't think struct "holes" have guaranteed behavior one way or the other.
>The destination hole might get random garbage, the source hole's contents,
>0 fill, or be left unchanged, depending on the implementation.
What about a machine which initialises its stack with parity errors
(or other trapping values) to trap some uses of a value before definition
(such programs are undefined).
Clearly if I (illegally) do
    f() { struct { int a,b; } x;
          x.b = 1;
          g(x);
       }
then I would expect undefined behaviour (and risk a trap).  How about
    f2() { struct { char a; int b; } x;
          x.a = 1, x.b = 1;
          g2(x);
       }
??
The same problem occurs with union values passed by value when the value is
not of the largest component.
Are we really saying that referencing *some* uninitialised locations
is not undefined?
See section 3.5.6 [initialisation] in Oct 86 DpANS for loose words.
--
Alan Mycroft am@cl.cam.ac.uk