This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?
- From: "Paul Koning" <Paul_Koning at Dell dot com>
- To: "Andrew Haley" <aph at redhat dot com>, "Andreas Schwab" <schwab at linux-m68k dot org>
- Cc: "Dave Korn" <dave dot korn dot cygwin at googlemail dot com>, <gcc at gcc dot gnu dot org>
- Date: Sun, 10 Jan 2010 09:39:45 -0500
- Subject: RE: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?
- References: <4B491A00.5090502@gmail.com> <m2pr5iw8tr.fsf@whitebox.home> <4B49B384.1070505@redhat.com>
> ...
> typedef unsigned char uint8_t;
> typedef unsigned int uint32_t;
>
> struct in6_addr
> {
> uint8_t __s6_addr[16];
> };
>
> static inline int
> address_in_use (unsigned char *a, struct in6_addr *in6)
> {
> if ((((const uint32_t *)(a))[0]
> == ((const uint32_t *)(in6->__s6_addr))[0]
> && ((const uint32_t *)(a))[1]
> == ((const uint32_t *)(in6->__s6_addr))[1]
> && ((const uint32_t *)(a))[2]
> == ((const uint32_t *)(in6->__s6_addr))[2]
> && ((const uint32_t *)(a))[3]
> == ((const uint32_t *)(in6->__s6_addr))[3]))
> return 1;
>
> return 0;
> }
That code seems to be broken for reasons other than aliasing -- it can
easily give alignment errors on platforms that require natural alignment
(because an in6_addr object might be allocated at an odd address).
paul