Re: [lwip-devel] [bug #35875] #define ⇒ enum?

[David Empson]

On 2012-03-20 10:42, Bill Auerbach wrote:
> David Empson wrote:
>>
>> One argument against using enums (admittedly weak): some compilers,
>> including one we are using, implement enums as unsigned instead of
>> signed integers, in violation of C standards. Attempting to declare a
>> negative enum value produces an error. I generally prefer to use enums
>> for named constants, but with this compiler I've had to use #define for
>> negative values.
> 
> David,
> 
> You mean this is an error:
> 
> enum someEnum { Val1 = 1, Val2 = -1 };
> 
> What about:
> 
> enum someEnum { Val1 = 1, Val2 = -1U };
> 
> or
> 
> enum someEnum { Val1 = 1, Val2 = (unsigned) -1 };
> 
> That reall is an odd thing for a compiler - I could see using unsigned if no
> member is<  0 but to default to unsigned isn't good.  And it's really easy
> to resolve if the compiler is still being maintained.

Had to refresh my memory by doing some test code and loading it into the
debugger.

It is worse than that. There is no error or warning produced by using a
negative value in the enum, but a variable using the enum type is
treated as unsigned. This means ordered comparisons based on a negative
value produce the wrong comparison.

e.g.

enum someEnum {Val1 = 1, Val2 = -1U};

enum someEnum myVar;

if (myVar >= Val2) {    
        /*...*/
        }

produces code which does an unsigned comparison of myVar to 65535U and
only executes the code if the value is equal to 65535U, not if it is
zero or positive.

The compiler is not being maintained so we can't fix it.

A workaround is to avoid declaring variables of the enum type, instead
using int, signed char or similar, but that makes it harder to debug
because the debugger no longer shows symbolic names for the values.