Re: typedef enums are now unsigned?!
Re: typedef enums are now unsigned?!
- Subject: Re: typedef enums are now unsigned?!
- From: Darcy Brockbank <email@hidden>
- Date: Sun, 08 Mar 2009 13:36:41 -0400
- Organization: Quarrelsome Logick and Divination, Inc.
Clark Cox wrote:
This is simply incorrect. From the C standard:
"Each enumerated type shall be compatible with char, a signed integer
type, or an unsigned integer type. The choice of type is implementation-defined,
but shall be capable of representing the values of all the members of the enumeration."
That is, the underlying type can be *any* integer type, not just int.
You missed the relevant parts of the standard you're quoting. What you are
referring to are the options available to the compiler after it has
considered the
enum in question.
Valid values of the enum are explicitly stated in items (2) and (3)
which are
directly above item (4) which you are quoting. The relevant section is
6.7.2.2
if anyone would like to read.
Item (2):
"The expression that defines the value of an enumeration constant shall
be an integer
constant expression that has a value representable as an int. "
Note: *not* an unsigned integer, but an int. -1 is a valid choice in an
enum.
Item (3):
"The identifiers in an enumerator list are declared as constants that
have type int and
may appear wherever such are permitted."
Note: enum type is "int". Period.
The salient portion of Item (4) is:
"The choice of type is implementation-defined, *****but***** shall be
capable of
representing the values of all the members of the enumeration."
This states that the compiler can freely choose between char, short int,
unsigned
short int, int, unsigned int, etc., *provided* that the choice is
capable of representing
all of the values in the enum.
Furthermore 6.2.2 states in item (16):
"An enumeration comprises a set of named integer constant values. Each
distinct
enumeration constitutes a different enumerated type."
Item (17):
"The type char, the signed and unsigned integer types, and the
enumerated types are
collectively called 'integer types'. The integer and real floating types
are collectively called
real types."
So any individual enumerated type, without knowing what you have, may not be
equivalent in type to any other (by definition it isn't), however, they
are based on
integer constant values and an enum has an integer type. Whatever
constant values
you pick for the enum is going to result in the compiler's decision
about the representation
of the enum, but it's going to have an integer type as per 6.2.2.17,
6.2.7.3 and
integer values are allowed as per 6.2.7.2, 6.2.7.3, 6.2.7.16 and 6.2.7.17.
This change doesn't have to be documented, because you were relying on
something that wasn't guaranteed by the language in the first place.
Not only does a deviation from the standard have to be documented, but it
is a deviation from the standard so the documentation in question should
be a bug report.
- darcy
so I thought this meant it was OK to return -1
in the method if an error occurs.
The only way that you can guarantee that you are allowed to assign -1
to an enum type is to have one of its members have a value less than
or equal to -1.
Well, on PPC and X86 the method was indeed returning -1 when an error
occurred, but on PPC64 and X86-64, it was instead returning 2^32-1, which is
SOP for a method returning an unsigned int, not an int. This, of course,
threw off various checks for -1, and flew in the face of what it says in
TCPL.
I was able to work around this by changing the results of an error from -1
to INT_MAX, but this raises several questions: Why did this change in the
64-bit compilers, where is this change documented, and how can this behavior
be controlled?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden