[Top][All Lists]
[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: |
Mon, 23 Oct 2006 12:35:29 +0200 |
> > 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