On Jan 31, 2011, at 3:51 PM, Pawel Jakub Dawidek wrote: > On Mon, Jan 31, 2011 at 10:56:18PM +0000, FreeBSD Tinderbox wrote: > [...] >> cc -O2 -pipe -I/src/sbin/hastctl/../hastd -DINET -DINET6 -DYY_NO_UNPUT -DYY_NO_INPUT -DHAVE_CRYPTO -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/hastctl/../hastd/proto_common.c >> cc1: warnings being treated as errors >> /src/sbin/hastctl/../hastd/proto_common.c: In function 'proto_common_descriptor_send': >> /src/sbin/hastctl/../hastd/proto_common.c:116: warning: cast increases required alignment of target type >> /src/sbin/hastctl/../hastd/proto_common.c: In function 'proto_common_descriptor_recv': >> /src/sbin/hastctl/../hastd/proto_common.c:146: warning: cast increases required alignment of target type >> /src/sbin/hastctl/../hastd/proto_common.c:149: warning: cast increases required alignment of target type >> *** Error code 1 > > Marcel, do you have an idea how one can use CMSG_NXTHDR() on ia64 with > high WARNS? With WARNS=6 I get those errors and I've no idea how to fix > it properly. If there is a fix, CMSG_NXTHDR() should probably be fixed, > but maybe I'm wrong? this warning indicates that you're casting from a pointer to type P (P having alignment constraints Ap) to a pointer to type Q (Q having alignment constraints Aq), and Aq > Ap. The compiler tells you that you may end up with misaligned accesses. If you know that the pointer satisfies Aq, you can cast through (void *) to silence the compiler. If you cannot guarantee that, you have a bigger problem. Solutions include "packing" type Q to reduce Aq or to copy the data to a local variable. Take the statement at line 116 for example: *((int *)CMSG_DATA(cmsg)) = fd; We're effectively casting from a (char *) to a (int *) and then doing a 32-bit access (write). The easy fix (casting through (void *) is not possible, because you cannot guarantee that the address is properly aligned. cmsg points to memory set aside by the following local variable: unsigned char ctrl[CMSG_SPACE(sizeof(fd))]; There's no guarantee that the compiler will align the character array at a 32-bit boundary (though in practice it seems to be). I have seen this kind of construct fail on ARM and PowerPC for example. In any case: The safest approach here is to use le32enc or be32enc rather than casting through (void *). Obviously these function encode using a fixed byte order when the original code is using the native byte order of the CPU. Having native encoding functions help. You could use bcopy as well, but the compiler is typically too smart for its own good and it will try to optimize the call away. This leaves you with the same misaligned access that you tried to avooid by using bcopy(). You need to trick the compiler so that it won't optimize the bcopy away, like: bcopy((void *)&fd, CMSG_DATA(cmsg), sizeof(fd)); HTH, -- Marcel Moolenaar xcllnt_at_mac.comReceived on Mon Jan 31 2011 - 23:56:24 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:11 UTC