Simon,
>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).
Noted. Didn't accept all changes, wasn't sure about a few
and I hate introducing typecasts or unsized types for sake of
style and portability (what is sizeof(int) or what is MAX_INT?).
Some lines are going to change anyway.
Hope I can find a few minutes this evening to work on mem.c.
>Have you been able to compile the stack cleanly?
More or less cleanly, still get a few warnings.
Some of these are actually portability problems, no ANSI C issues,
or things I that I consider to be on my todo list.
(clock_t type, some 64 bit arithmatic in perf.c not possible
on embedded archs, need to complete SNMP TCP connection table etc)
>If so, what platform are you using?
Currently using OpenBSD3.9 on i386 gcc 3.3.5 plus OpenBSD patches.
I've also tried a bleeding-edge Gentoo, with a bleeding-edge GCC 4.1.1,
which results in a horriffic amount of warnings on struct packing. :-(
Also using the c16x / Tasking port, without warnings,
only using the 'core' and 'contrib' files.
(but I don't trust this compiler error reporting capability)
> -Wcast-align switch is turned on.
>Nevertheless, I think this is a severe warning which should be taken
>care of!
Hmm. Doesn't -Wall -pedantic turn this on?
>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...
Simply be more explicit in cc.h, typedef your s8_t to signed char.
>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.
Thanks for hinting.
>Hoping for lots of comments... ;-)
Enough?
Christiaan Simons
Hardware Designer
Axon Digital Design
http://www.axon.tv