macro for enum operations

[Lubos Lunak]

On Thursday 11 of September 2003 14:23, Michael Matz wrote:
[snip]
> > > > I am particularly concerned about the "~"  operator because the
> > > > return value needs to be converted to EnumType again and I wonder
> > > > whether truncation would cause problems with 1s complement vs 2s
> > > > complement.
> > >
> > > ~ is indeed conceptually a problem.  Not because of 1s vs 2s
> > > complement, but because of the backcast.  Given this:
> > >
> > > enum E {a,b,c};
> > > long l = ~(long)a;
> > > enum E e = (enum E)l;
> > >
> > > the problem arises because l has the value -1L.  This is outside the
> > > values of enum E, and hence the resulting enumeration value is
> > > unfortunately unspecified.  It could be truncated, or anded, or the
> > > machine could explode.  The problem of course is, that without the
> > > operator ~, the others make much less sense.  For instance it's
> > > possible to set some bit by |, but it's impossible to remove it again
> > > (by & and ~). Choose your poison.
> >
> > Would this be a problem even when using unsigned long instead of long?
>
> In that case 'l' would have value (unsigned long)-1L (i.e. all bits set),
> which _also_ lies outside the values of enum E.
>
> > Perhaps that could be fixed by passing bitmask of valid bits to the
> > macro.

 Then the bitmask would fix it. Or even simpler, the macro could require that 
the enum has one entry with value 1 << 31  (or 1<<63, if the macro would use 
unsigned long long). That would also avoid the problem with extending the 
enum later.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/