RE: [lwip-users] Compiler warnings

[Goldschmidt Simon]

> > The third issue is that GCC warns me about indexing an array with a 
> > 'char' in etharp.c (lines 369, 449 & 751). Don't know why 
> this doesn't 
> > work. 'Signed char' and 'int' work, though...
> 
> It's simply following what the C standard says: "One of the 
> expressions shall have type ''pointer to object type'', the 
> other expression shall have integer type, and the result has 
> type ''type''."
> 
> A simple cast to int (e.g. arp_table[(int)i].state or 
> whatever) may be sufficient. I've no idea why signed char 
> works though!
> 

I found that out by now: C standard does not define 'char' to be signed
or unsigned but leaves that to the compiler to decide. 'signed char' and
'unsigned char' both worked for me...

> > Fourth and last problem is that 'struct sockaddr' and 'struct 
> > sockaddr_in' don't have the same alignment since 'struct sockaddr' 
> > only has u8_t/char members. This can me fixed by 
> declaration 'struct 
> > sockaddr_in' as packed, although I don't see the need for this.
> 
> Anonymous unions would be nice, but that's too much of an 
> extension :-). 
> One solution might be a macro (to be defined in cc.h) to 
> allow alignment, so in gcc that would be 
> __attribute__((aligned(something))). But I think an 
> appropriate solution would be to add an element with stronger 
> alignment, e.g.
> 
> struct sockaddr {
>    u8_t sa_len;
>    u8_t sa_family;
>    u16_t sa_dummy;
>    char sa_data[12];
> };
> 
> According to the C standard, that may not strictly be 
> sufficient. But I think it might work everywhere in practice.
> 

I tried it with __attribute__((packed)) and that worked, although the
layout (and alignment) of the struct does effectively _not_ get changed.
Might be flaw in GCCs warnings?

> > And for the mem-alignment bugs in mem.c, memp.c and pbuf.c: I don't 
> > think it's the best approach to use u8-arrays for the pools. Better 
> > would be to use arrays of the structs the pools have to 
> use. This way, 
> > the mem-alignment would be taken care of by the compiler 
> (generating 
> > the
> > arrays) instead of the programmer.
> 
> It almost certainly wouldn't save any space though, just make 
> it more obvious what's going on.
> 

Of coures this doesn't save space, but it makes the code cleaner. With
the current code, you either get a warning when casting, or you cast
yourself by using MEM_ALIGN(x). In both cases, when changing the code,
you lose the compiler-check if the resulting pointer is really aligned
correctly!


Simon