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

[Bill Auerbach]

>-----Original Message-----
>From: David Brown [mailto:address@hidden
>Sent: Monday, March 19, 2012 10:43 AM
>Subject: Re: [bug #35875] #define ⇒ enum?
>
>Yes indeed - and the compiler will do exactly the same with an enum as
>with a #define'd value (and in most cases, also with a "static const").
> My point was not that a #define'd value was bad because it is a true
>"int", but that it is no different from an enum.
>

I think the underlying point is that t_s8 is 1 byte while the enum
declaration will take up sizeof(int) bytes.  The constant compares might be
identical but loading and storing the enum vs t_s8 will not be.

And this brings up a nit: LWIP is littered with signed variable declarations
where the values used with it are never negative.  Maybe it's just me that
does this, but I always use unsigned types unless the use will require
negative values.  Of course enum's are signed but I can't control that.  I
do use enums as much as possible because debugging is nicer to see the
member definitions and not numerics.

>Most embedded compilers will have a way of generating "short" enums,
>even though these are technically non-standard.  But when dealing with
>constant values for comparisons or assignments to shorter variables
>(like an u8_t), the code generated should be as small and fast as with a
>#define'd int.

I agree. I forgot to mention what Simon did - the storage requirements are
most likely going to be more for enums.

>True enough - the standards don't prevent the compiler from creating
>storage here.  But neither do the standards prevent the compiler from
>creating storage for a normal "int" constant (indeed, some compilers
>will actually do that - on some 32-bit RISC architectures it is more
>efficient to use a "load from memory via a small data pointer plus
>16-bit offset" instruction than a "load 16-bit immediate with shift"
>then a "or 16-bit immediate" instruction pair).

Interesting point - I didn't know this.  I presume also for enums they would
store the constant in memory.

>Having said that, not all compilers are equally good as such code
>generation - and support for poor compilers is a good reason for
>avoiding "static const" in portable code like this.

This we do agree on.  If it were very easy to try enums to compare results
on a few platforms it would surely be interesting to see the results.  It's
probably not a hard changeover to do - I'm willing to do it on 2 platforms
if there is serious interest in moving to enums.  One would be GCC 4.x
based, the other CodeWarrior PowerPC.