Re: [lwip-devel] PPP LCP Phases Not Enum in 2.0.0 Beta

[Greg Smith]

Hi, Sylvain.
Nevermind.  I just now thought about why you do have to make the variable of type enum; otherwise, the compiler won't know any different anyway.

So, perhaps I'll just make the change on my own system for debugging if I really get down to "needing" it.  In the meantime, I might think about some other options.

Thanks for looking into it for me.

-- G

> -----Original Message-----
> From: Greg Smith
> Sent: Tuesday, 02 August 2016 13:45
> 
> Hi, Sylvain.
> 
> > From: Sylvain Rochet
> > Sent: Monday, 01 August 2016 18:57
> >
> > On Tue, Aug 02, 2016 at 12:40:47AM +0200, Sylvain Rochet wrote:
> > > On Tue, Aug 02, 2016 at 12:22:11AM +0200, Sylvain Rochet wrote:
> > > > On Mon, Aug 01, 2016 at 09:50:30PM +0000, Greg Smith wrote:
> > > > > Hello.
> > > > >
> > > > > In Lwip 1.4.1, the PPP LCP states (phases) were all defined as
> > > > > an enum (typedef LinkPhase).  This made seeing the state in a
> > > > > debugger really nice -- it would show "PHASE_DEAD", for example.
> > > > > In 2.0.0 Beta1, they have been converted to #define macros.  Now
> > > > > the debugger only shows a number (0, for example), which isn't
> > > > > as
> > convenient.
> > > > >
> > > > > So:
> > > > >
> > > > > 1) I'd like to understand why this change was made.
> > > >
> > > > In C, an enum type is always an int, which is a 4-byte value on
> > > > 32-bit systems (also 4-byte on LP64, LLP64, and 8-byte on ILP64,
> > > > but we are a bit outside lwIP targets here). So this is to save 3
> > > > (or 7) bytes of RAM per state value, and it matters.
> 
> I don't see how enum uses any extra RAM compared to literals.  #define macros,
> similar to enum, are also a minimum of type int.  (Well, technically, the
> numeric constant (literal) that the preprocessor replaces in the text is at
> least of type/size int.  C99:6.4.4.1)
> 
> Since C, unlike C++, doesn't treat enums as purely their own type (they're just
> int after all), they can easily be stuffed into any primitive type of
> sufficient size -- just as any numeric literal (#define) can.
> 
> For example, fsm.state can still be a u8_t type (i.e. no need to explicitly
> change it to type enum); the compiler will implicitly do the casting for you
> (so you don't even have to explicitly cast) and the value stored in RAM for the
> state is only a single byte.  (Well, assuming the compiler doesn't pad the
> struct up to a 2- or 4- byte boundary, which it probably does.  If it does,
> then the whole RAM argument is invalid anyway because it is taking up extra
> bytes for padding).
> 
> But to prove it to myself I changed the PPP_FSM_* to an enum type and
> recompiled my whole project (using gcc).  I compared the emitted assembly for
> just one function (I'm lazy), fsm_lowerup(), and it was identical opcodes to
> the #define version.
> Additionally, the compiler/linker-reported text, data, and bss sizes were also
> identical between the two.
> 
> -- G

---

This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com

---