Re: RE: [lwip-devel] Curious struct packing issue - is it GCC?

[Simon Goldschmidt]

> Things in headers will be u16_t aligned.

Are they? I didn't recognize that. But if so, I guess you're lucky about the 
protocols that they don't use bytes...

> The once place we SMEMCPY to a
> header is the netif mac address which wasn't aligned.

As I wanted to say at the end of my last mail: For now, it is like that, but it 
could well be that this changes in the future - If we ever need to copy a small 
amount of bytes that are unaligned, we would use SMEMCPY, too!

> Shouldn't we do what we can so we're not using memcpy to copy 4, 6,or 14 
> bytes?

Of course, and that's why SMEMCPY was introduced and we are right now 
discussing about optimization :-)

> It would be nice if the hwaddr could be aligned (u16_t) if one wanted the
> inlined SMEMCPY moving u16_t's.

I thought about that, too. For ethernet this is OK, but I don't know about 
other networks that use netif->hwaddr. What's left as protocols there anyway 
aside from ethernet? PPP? SLIP? They don't use DHCP, do they? The thing is that 
SNMP also uses netif->hwaddr and it could well be used with PPP and/or SLIP...

Of course we could better optimize if the address only was for ethernet, but it 
doesn't seem to be.

> Seems to me that hwaddr_len and a u8_t *hwaddr (pointer to)
> should be filled in by the low level init code.

That's correct. As can be seen in the example ethernetif.c (or so I think).

> Wouldn't it be slightly better to store the pointer to the hwaddr?

I guess so, yes. But don't ask me why it's not done that way. Maybe to make it 
easier for C-beginners to not fall into variable-lifetime-pits ;-)

BTW, we are working a bit on our lwIP-related project again (also on NIOS-II), 
and I hope to find the time to include your macros there to test them!

Simon
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01