From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <43a5572d-ea50-41a8-9897-9900f13c5a00@www.fastmail.com> <20190402003532.GA55021@wopr> In-Reply-To: <20190402003532.GA55021@wopr> From: Dan Cross Date: Mon, 1 Apr 2019 21:20:43 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="00000000000011fb0e0585820069" Subject: Re: [9fans] Don't Plan 9 C compiler initialize the rest of member of a?struct? Topicbox-Message-UUID: f7d40042-ead9-11e9-9d60-3106f5b1d025 --00000000000011fb0e0585820069 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 1, 2019 at 8:36 PM Kurt H Maier wrote: > On Mon, Apr 01, 2019 at 08:26:30PM -0400, Jeremy O'Brien wrote: > > On Mon, Apr 1, 2019, at 11:33, Kyohei Kadota wrote: > > > Hi, 9fans. I use 9legacy. > > > > > > About below program, I expected that flags field will initialize to > > > zero but the value of flags was a garbage, ex, "f8f7". > > > Is this expected? > > > > > > ``` > > > #include > > > > > > struct option { > > > int n; > > > char *s; > > > int flags; > > > }; > > > > > > int > > > main(void) > > > { > > > struct option opt = {1, "test"}; > > > printf("%d %s %x\n", opt.n, opt.s, opt.flags); > > > return 0; > > > } > > > ``` > > > > > > > > > > According to C99: "If an object that has automatic storage duration is > not initialized explicitly, its value is indeterminate." > > > > Stack variable == automatic storage duration. This appears to be correct > behavior to me. > > > > Can anyone provide the patches 9legacy uses to implement C99 compliance? There were actually quite a few of them, mostly done by Geoff Collyer. The compiler sources list contains a list of desiderata in a file called `c99`; of course, the plan9 compilers aren't completely compliant (they weren't trying to be). Incidentally this file has been carried forward into, for example, /sys/src/cmd/cc/c99 in the 9front distribution (and other plan9 derivatives). In the present case, this appears to be a compiler bug. The aforementioned reference to n1548 sec 6.7.9 para 10 is incorrect in that there _is_ an explicit initializer here. The relevant text in the standard is sec 6.7.9 pp 16-21, which specifies that in the event that an explicit initializer does not completely cover (in a topological sense) the thing it is initializing, then the elements not covered shall be initialized as if they had _static_ storage duration; that is, they should be zeroed. Now as I said, the Plan 9 C compilers aren't explicit C99 compliant. But given that the `c99` file describes things related to initializer lists as being unneeded because they were already implemented, one may assume it was believed that this was covered by c99 behavior. It isn't. - Dan C. --00000000000011fb0e0585820069 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Apr 1, 2019 at 8:36 PM Kurt H Mai= er <khm@sciops.net> wrote:
<= /div>
On Mon, Apr 01, 2019 at 08:26:30PM -0400, Jeremy O'Brien wrote:<= br> > On Mon, Apr 1, 2019, at 11:33, Kyohei Kadota wrote:
> > Hi, 9fans. I use 9legacy.
> >
> > About below program, I expected that flags field will initialize = to
> > zero but the value of flags was a garbage, ex, "f8f7".<= br> > > Is this expected?
> >
> > ```
> > #include <stdio.h>
> >
> > struct option {
> >=C2=A0 =C2=A0 =C2=A0int n;
> >=C2=A0 =C2=A0 =C2=A0char *s;
> >=C2=A0 =C2=A0 =C2=A0int flags;
> > };
> >
> > int
> > main(void)
> > {
> >=C2=A0 =C2=A0 =C2=A0struct option opt =3D {1, "test"}; > >=C2=A0 =C2=A0 =C2=A0printf("%d %s %x\n", opt.n, opt.s, o= pt.flags);
> >=C2=A0 =C2=A0 =C2=A0return 0;
> > }
> > ```
> >
> >
>
> According to C99: "If an object that has automatic storage durati= on is not initialized explicitly, its value is indeterminate."
>
> Stack variable =3D=3D automatic storage duration. This appears to be c= orrect behavior to me.
>

Can anyone provide the patches 9legacy uses to implement C99 compliance?

There were actually quite a few of them, most= ly done by Geoff Collyer.=C2=A0 The compiler sources list contains a list o= f desiderata in a file called `c99`; of course, the plan9 compilers aren= 9;t completely compliant (they weren't trying to be). Incidentally this= file has been carried forward into, for example, /sys/src/cmd/cc/c99 in th= e 9front distribution (and other plan9 derivatives).

In the present case, this appears to be a compiler bug. The aforemention= ed reference to n1548 sec 6.7.9 para 10 is incorrect in that there _is_ an = explicit initializer here. The relevant text in the standard is sec 6.7.9 p= p 16-21, which specifies that in the event that an explicit initializer doe= s not completely cover (in a topological sense) the thing it is initializin= g, then the elements not covered shall be initialized as if they had _stati= c_ storage duration; that is, they should be zeroed.

Now as I said, the Plan 9 C compilers aren't explicit C99 compliant.= But given that the `c99` file describes things related to initializer list= s as being unneeded because they were already implemented, one may assume i= t was believed that this was covered by c99 behavior. It isn't.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.

=

--00000000000011fb0e0585820069--