On Thu, Jan 26, 2012 at 08:09:13PM +0100, Peter J. Philipp wrote:
> On Thu, Jan 26, 2012 at 07:22:37PM +0100, Otto Moerbeek wrote:
> > > cc -Wall -g -I/usr/local/include/db4 -c reply.c
> > > reply.c: In function 'create_anyreply':
> > > reply.c:2975: warning: array size (2) smaller than bound length (4)
> > > reply.c:2975: warning: array size (2) smaller than bound length (4)
> > > cc -Wall -g -I/usr/local/include/db4 -c additional.c
>
> <some cut>
>
>
> >
> > 2553 struct answer {
> > 2554 u_int16_t type; /* 0 */
> > 2555 u_int16_t class; /* 2 */
> > 2556 u_int32_t ttl; /* 4 */
> > 2557 u_int16_t rdlength; /* 8 */
> > 2558 char rdata[0]; /* 10 */
> > 2559 } __packed;
> >
> > Since rdate is an array, there's at least a redundant &.
> >
> > Zero sized arrays are actually not legal and a gnu extension. With
> > ANDSI C, use [1] but note it changes the size of the struct), and with
> > C99 use [].
> >
> > -Otto
>
> When I changed it to "char rdata[4];" on line 2558 like you pointed me to
> the message disappeared. Now correct me if I'm wrong, __packed or
> __attribute__((packed)) which I throw out due to some code example eons ago,
> should have packed the struct below a 2 byte boundary or something. Is this
> functionality gone now? Because when I do rdata[4], the size of the struct
> should be 14 bytes which lies on a 2 bytes boundary. Thankfully my code is
> forgiving on an rdata[4]. At least at first sight.
>
> Thank you for solving my problem! (Thanks to Christiano too!)
>
> -peter
This of course depends on the exact alignment rules of the
architecture you're compiling on. ttl has an offset of 4 bytes, so
your "even" rule might not be enough on strict alignment archs, since
padding is being added to the struct.
Especially if the struct is used to decode network data, beware.
There's is a reason we tell developers to test on sparc64, this arch
is very good at pinpointing alignment problems.
-Otto
