Help with bit-field semantics in C and C++
Gabriel Dos Reis
gdr@integrable-solutions.net
Wed Aug 25 05:06:00 GMT 2004
Mike Stump <mrs@apple.com> writes:
| On Tuesday, August 24, 2004, at 05:21 PM, Gabriel Dos Reis wrote:
| > At any single time, the value of an enum -- other than that of an
| > uninitialized variable -- is always a valid enumeration value, which is
| > always in the range of enumration value, here [0.3].
|
| Is this true when you use the type between C and C++ parts of a single
| program? If so, how?
C++ defines, see 7.2/6 what it means to be an enumeration value.
It documented the divergence from C in Annex C, see C.1.5.
Enums that are part of C++ programs are subject to C++ rules.
As far as your enumeration values are kept in range, there is no
reason to believe that the world will fall. Once you start fiddling
and playing with bits out of range, you're in trouble.
| Is this true when you have existing .o files compiled with older
| headers that have a subset of enumeration constants for a given enum?
Again, if you keep your enumration values in range, there is no reason
to believe you'll in trouble because the semantics is well-defined.
All C++ types, in particular enums, are subject to the One Definition
Rule. The One Definition Rule is crafted so that the C (therefore
C++) genuine separate compilation of model does not get into the way
when combining several compilation units.
| Or, do we just ignore the real world? Is the standard better if we do?
We don't ignore the real world. We do care about real world. Part of
my daytime job involves things like working on checking software, that
make sure that programs intended to do some tasks are effectively
written to meet the intent and are successfully compiled to do so --
some of those programs are part of flying objects. Some of them just
apply useful transformation/optimization derived from contraints
expressed as type annotations or other forms, to improve on the
robustness and efficiency of C++ programs. The unpleasant part of it
is compilers ignoring semantics specifications.
-- Gaby
More information about the Gcc
mailing list