lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-users] Compiler warnings


From: Goldschmidt Simon
Subject: RE: [lwip-users] Compiler warnings
Date: Fri, 20 Oct 2006 10:38:21 +0200

Christiaan (and all others interested in getting clean code :),
 
First, I would like to thank you for the fast integration of parts of
the patch, really nice work. I upgraded to the new version but still got
a few warnings. Apart from a signed/unsigned issue in socket.c
(resulting from sizeof() used in macro on line 90/91 being unsigned
while 'err' in line 94 is of type err_t which is signed), those are
mainly memory-alignment warnings (e.g. casts from u8_t to struct mem* in
mem.c, also in memp.c and pbuf.c).

Have you been able to compile the stack cleanly? If so, what platform
are you using? On a platform like x86 or an 8-bit-platform, those
warnings don't come, of course. Even on our NIOS-II platform, GCC only
generates this warning if the -Wcast-align switch is turned on.
Nevertheless, I think this is a severe warning which should be taken
care of!

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...

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.

I _could_ submit a patch for the first 2 issues, but I'm not sure what
to do about the etharp-warning and the struct sockaddr_in. Does anyone
have any comments about this?

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.


Hoping for lots of comments... ;-)

Simon.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]