Definition With Incomplete Type Should Be An Error

Norman Diamond diamond at jit345.swstokyo.dec.com
Fri Mar 29 17:07:18 AEST 1991


In article <509f2397.20b6d at apollo.HP.COM> blodgett at apollo.HP.COM (Bruce Blodgett) writes:

>Are my comments about the following program correct?  I feel that that
>the declarations of s1 and a2 should ideally require a diagnostic.

Both of them violate "shall" assertions in SEMANTICS sections.
Neither of them violates any assertion in CONSTRAINTS sections.
Therefore they both yield undefined behavior, and neither of them
requires a diagnostic.  (Though high-quality processors would produce
diagnostics for both.)

>static int s1[]; /* Violates a "shall" requirement: */
>External Object Definitions 3.7.2 p 84 l 29: ...
>The declaration of array s1 is a tentative definition.
>Linkages of Identifiers 3.1.2.2 p 22 l 14: ...
>s1 has internal linkage.
>Array Declarators 3.5.4.2 p 68 l 9: ...
>Array s1 has incomplete type.
>External Object Definitions 3.7.2 p 84 l 35: ...
>Definitions of Terms 1.6 p 3 l 42:  If a "shall" ... requirement that
>appears outside of a constraint is violated, the behavior is
>undefined.

Yes.

>extern void main(void)
Let's correct this to extern int main(void) and continue.
>{ auto int a2[]; /* Undefined behavior? */
>Array Declarators 3.5.4.2 p 68 l 9: ...
>Array a2 has incomplete type.
>Linkages of Identifiers 3.1.2.2 p 22 l 24: ...
>Array a2 has no linkage.

Yes, and let's continue.

>Declarations 3.5 p 58 l 17: ...
>There shall be no more declarations of array a2 in this scope.

That paragraph has no bearing on this example.  However, this one does --
Declarations 3.5 p 58 l 30:
If an identifier for an object is declared with no linkage, the type for the
object shall be complete by the end of its declarator, or by the end of its
init-declarator if it has an initializer.

--
Norman Diamond       diamond at tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.



More information about the Comp.std.c mailing list