🚀 go-pugleaf

diamond@jit345.bad.jit.dec.com (Norman Diamond) writes:
>In article <1992Mar28.153738.20577@mcshh.Hanse.DE> buster@mcshh.Hanse.DE (Andreas Burmester) writes:
>>To handle strings, I've typedefed
>>        typedef char CA[];
>>and ran into a problem, I could track down to these definitions:
>>(0)     CA s0 = "string 0";
>>(1)     CA s1 = "s1";
>>(2)     CA s2 = "this is string 2";
>>The translator passes (0) and (1), while at (2), it complains
>>that "The initializer length exceeds the aggregate length." A
>>closer inspection reveals already at (1) things go (at least for
>>me) unexpected ways: There are 9 bytes allocated for s1 - note,
>>that strlen(s0) == 9 !
>>It's obvious that, having processed (0), CA is 'retypdefed' to
>>char CA[9]. Then the initializer of s2 is indeed too long.

>My understanding of "Array declarators" (ANSI 3.5.4.2) is that the type CA
>is an array type and is an incomplete type.  [3.5.4.2 is missing from the
>index for "type, incomplete" in the last draft edition.]

And in the final version, but it adds no new information over the first
definition in "Types", which is probably the reason for the omission.

>My understanding of "Initialization" (ANSI 3.5.7) is that when an array of
>unknown size is initialized, the array is the one in the declarator.  The
>array whose size is determined by the number of initializers, and which no
>longer has incomplete type, is the one in the declarator.  This would be
>s0, s1, or s2.  I don't believe that it would be CA.

The key here, I think, is that the type of s0, s1, and s2 is not "CA".
The type of those objects is array-N-of-char, where N is filled in when
the object is fully declared.  The identifier CA is just "a synonym for
an existing type", namely array-incomplete-of-char.  Typedefs are not types.

This compiler is wrong from ANSI's viewpoint.