Paul Burba wrote:
> Hello All,
>
> Note: This is *not* an iSeries specific question, so please don't let your
> eyes glaze over at the start :-)
>
Yes, yes ...
Anyway: Looking at this from a strictly standards-compliance point of
view, this is certainly a bug in your compiler. The C standard (both C90
and C99) allow enum types to be the smallest size that can represent all
the enumeration constants, provided that
* this type is the same as one of the standard integral types (char,
short, int, long, long long),
* that the type can represent the enumeration constants and all
their bitwise-ored combinations
In other words, the intent of the standard is that bitwise logical
operations with enumeration constants work as expected, regardless of
the exact size of the enumeration type.
[...]
> "...enumerated data types in Standard C...act as little more than slightly
> readable ways to name integer constants. As a matter of style, we suggest
> that programmers treat enumerated types as different from integers and not
> mix them in integer expressions without using casts. In fact, some UNIX C
> compilers implement a weakly typed form of enumerations in which some
> conversions between enumerated types and integers are not permitted
> without casts."
>
All such compilers are broken. For one thing, regardless of the enum
type itself, in C the enumeration _constants_ defined in the enum have
type int! Also, when mixing enum-typed variables with other integral
types in an expression, standard integral type promotion rules apply
(that's one reason for the requirement that the actual type of the enum
be equivalent to one of the standard integral types).
(Note that C++ is a different beast, with stronger typing rules for
enums. But we're not concerned with C++ here.)
I think your solution to force the compiler to always use int-sized
enums is correct in this case. The Subversion code conforms to the
standard in this particular instance.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 19 01:46:55 2006