Re: wider-than-int enums broken in C++

[Geoff Keating <geoffk at geoffk dot org>]

> X-Original-To: geoffk@foam.wonderslug.com
> From: Mark Mitchell <mark@codesourcery.com>
> Cc: Jason Merrill <jason@redhat.com>, rsandifo@redhat.com,
>    gcc-patches@gcc.gnu.org
> Date: 24 Jul 2003 00:15:46 -0700
> X-OriginalArrivalTime: 24 Jul 2003 07:12:52.0312 (UTC) FILETIME=[FF248D80:01C351B2]
> 
> On Wed, 2003-07-23 at 23:50, Geoff Keating wrote:
> > Jason Merrill <jason@redhat.com> writes:
> > 
> > > On 23 Jul 2003 23:50:15 -0300, Alexandre Oliva <aoliva@redhat.com> wrote:
> > > 
> > > > Your patch for PR 10796, that implemented C++ DR377, also contained a
> > > > code clean-up that was actually wrong.  The underlying type of an enum
> > > > must be an integral type, but, after your patch, we end up with a type
> > > > whose precision is given by the min and max values of the enumeration,
> > > > that doesn't necessarily match the precision of any of the integral
> > > > types.
> > > 
> > > How did this break the testcase?  I thought the point of TYPE_PRECISION was
> > > to describe the expressible values.  We set TYPE_PRECISION to 1 for bool
> > > even though we allocate more than one bit for it.
> > 
> > But, for enums, you can express any value that fits in the type, correct?
> 
> Not in C++.
> 
>   For  an  enumeration where emin is the smallest enumerator and emax is
>   the largest, the values of the  enumeration  are  the  values  of  the
>   underlying  type  in  the range bmin to bmax, where bmin and bmax are,
>   respectively, the smallest and largest values  of  the  smallest  bit-
>   field that can store emin and emax.

So at least the following is valid:

enum {
  a, b, c, d, e
} x;

x = 7;

because the bitfield must have at least 3 bits.

-- 
- Geoffrey Keating <geoffk@geoffk.org>