How soon can `sizeof (tagged_type)' be used?

Henry Spencer henry at zoo.toronto.edu
Sun May 19 07:49:45 AEST 1991


In article <519a28cf.20b6d at apollo.HP.COM> blodgett at apollo.HP.COM (Bruce Blodgett) writes:
>>>enum E { red, green = sizeof (enum E), blue };
>Section 3.1.2.1 states:
>"enumeration tags have scope that begins just aftert the appearance of
>the tag in a type specifier that declares the tag."

Hmm, you're right, I missed that one.

>The question becomes, "does enum E have incomplete type inside its
>enumerator-list?"
>
>Section 3.1.2.5 defines incomplete types as:
>"types that describe objects but lack information needed to determine
>their sizes".

No, that phrase appears to be an informal description rather than a precise
definition.  The standard never defines what information is needed to
determine sizes; it merely describes two specific constructs (array without
dimension and struct/union without declaration list) that generate incomplete
types.  In fact, in the discussion of tags (3.5.2.3) there is a footnote
indicating that the committee thought it was clear that enums could not
be incomplete.  Certainly there is no discussion for enum analogous to
that for struct/union about how an incomplete type comes into existence.

(That same footnote indicates that they thought other types could not depend
on the details of the declaration of an enumerated type, which is, of course,
wrong when sizeof comes into the picture.)

I don't think the matter can be settled cleanly by reference to the existing
standard.  Some ambitious soul might want to submit a request for a formal
interpretation.  However, there does seem to be trouble lurking here for an
implementation that tries to custom-tailor the sizes of enumerated types.

>Therefore the definition
>   enum E { red, green = sizeof (enum E), blue };
>relies upon implementation-defined behavior.

No, it relies on behavior that is not clearly specified by the standard.
"Implementation defined" has a specific meaning in ANSI-C-speak, and this
isn't it.  It would probably be better to assume that the relevant behavior
is undefined, meaning that anything can happen and users should avoid the
construct entirely.
-- 
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  henry at zoo.toronto.edu  utzoo!henry



More information about the Comp.std.c mailing list