[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 3 of 6] x86/mm: Another couple of comparisons of unsigned vars with < 0



>>> On 05.04.12 at 16:08, Tim Deegan <tim@xxxxxxx> wrote:
> At 14:31 +0100 on 05 Apr (1333636297), Jan Beulich wrote:
>> >>> On 05.04.12 at 14:07, Tim Deegan <tim@xxxxxxx> wrote:
>> > # HG changeset patch
>> > # User Tim Deegan <tim@xxxxxxx>
>> > # Date 1333626954 -3600
>> > # Node ID 5eeaa7b25a60327c48bf17472e9a00bdfc67378f
>> > # Parent  0ecf439475e12f185553f42f56f099be5f328cce
>> > x86/mm: Another couple of comparisons of unsigned vars with < 0.
>> > 
>> > Adding the explicit (unsigned) casts in case enums ever end up signed.
>> 
>> Ugly, but unavoidable if range comparisons are done on enums (which
>> is what ought to get fixed instead imo).
> 
> Any suggestions for how?  Turn the array access into a case statement?
> That's even uglier IMO. 

        switch (<enum-var>) {
        case <low> ... <high>:
                break;
        default:
                <bad>;
        }

doesn't look that bad. But when wanting to do range comparisons,
an enum may not be the best choice anyway (for the very reason of
it possible being signed, and signed array indexes generally being
less efficient than unsigned ones), and hence using #define-s and
an "unsigned int" variable might be the better way.

Otoh, doesn't clang have a command line option to control whether
enums are signed or unsigned? I think gcc does.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.