This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: underlying type for enums


Richard Henderson <rth@redhat.com> writes:

> On Tue, Dec 02, 2003 at 11:01:11AM -0800, Zack Weinberg wrote:
>> Either way, it's an "integral type consisting of the specified number
>> of bits" which is just what we want.
>
> Interesting.  What does C90 say about integer conversion rank
> wrt these types?  Cf section 6.3.1.1 in C99:
>
>    -- The rank of a signed integer type shall be greater than the rank
>       of any signed integer type with less precision.
>
> which, for C99 means that "unsigned int f : sizeof(int)*CHAR_BIT - 1"
> has rank < "int", and thus f+1 is type int and not unsigned int.
> I do seem to recall there's some difference here between C90 and C99.
>
> Perhaps that works the same, and is the bug Neil and Joseph have been
> attempting to solve for N years...

C90 doesn't have the concept of "integer conversion rank".  It does
have section 6.2.1.1 on the "integer promotions":

  A {char}, a {short int}, or an {int} bit-field, or their signed or
  unsigned varieties, may be used in an expression wherever an {int}
  or {unsigned int} may be used.  If an {int} can represent all values
  of the original type, the value is converted to an {int}; otherwise,
  it is converted to an {unsigned int}.  These are called the
  /integral promotions/.(27) All other arithmetic types are unchanged
  by the integral promotions.

(27) The integral promotions are applied only as part of the usual
     arithmetic conversions (6.2.1.5), to the operands of the unary
     +, -, and ~ operators, and to both operands of the shift operators.

I read this as meaning that your example is treated the same in both
C90 and C99.

It is not clear to me what to do with long int bitfields.  I think
they get converted to long int.  6.2.1.5 does not state whether an
operand with type long int bitfield is regarded as having type long
int.  If it isn't, then they might get truncated to int under some
conditions, which would be silly, so I'm betting they aren't; but then
"long int f : sizeof(int)*CHAR_BIT - 1" should be treated as long even
though int can represent all values of the original type, which would
be fine but would be a difference from C99.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]