How soon can `sizeof (tagged_type)' be used?
Bruce Blodgett
blodgett at apollo.HP.COM
Fri May 17 05:44:00 AEST 1991
In article <1991May13.175830.7143 at zoo.toronto.edu> henry at zoo.toronto.edu (Henry Spencer) writes:
>In article <5506 at lupine.NCD.COM> rfg at lupine.ncd.com (Ron Guilmette) writes:
>>Are either or both of these examples legal?
>>
>>enum E { red, green = sizeof (enum E), blue };
>>struct S { int i; int j : sizeof (struct S); int k; };
>
>I think neither.
>
>In the first one, the argument of sizeof is meaningless, because E is not
>declared until the end of the brace-enclosed list. Enums, unlike structs
>and unions, cannot be incomplete types.
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."
So enum tag E is in scope at the sizeof(enum E).
Section 3.3.3.4 lists the following Constraint:
"The sizeof operator shall not be applied to an expression that has ...
an incomplete type"
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".
The question becomes, "does enum E lack information needed to
determine its size inside its enumerator-list?"
Section 3.5.2.2 states:
"Each enumerated type shall be compatible with an integer type; the
choice of type is implementation-defined."
The implementation could choose exactly one integral type with which
to make all enumerated types compatible. In this case, enum E has
enough information to determine its size inside its enumerator-list.
Alternately, the implementation could tailor each enumerated type to
be the smallest integral type sufficient to store any of its member's
values (to save on disk space). In this case, enum E does NOT have
enough information to determine its size inside its enumerator-list.
Therefore the definition
enum E { red, green = sizeof (enum E), blue };
relies upon implementation-defined behavior.
Bruce Blodgett
blodgett at apollo.hp.com
(508) 256-0176 x4037
More information about the Comp.std.c
mailing list