-- NOTE -- Please Cc: me on replies, I am not subscribed to freebsd-net.
Greetings,
I am just staring at gcc 4.8 warnings when compiling the try.c code
shown below:
----------------------------------------------------------------
$ cat try.c
#include <sys/types.h>
#include <sys/socket.h>
#include <unistd.h>
#include <netinet/in.h>
int f(void) {
struct sockaddr_in6 sin6;
int r = IN6_IS_ADDR_V4MAPPED((&sin6.sin6_addr));
return r;
}
----------------------------------------------------------------
----------------------------------------------------------------
$ gcc48 -Wall -O2 -c try.c
try.c: In function 'f':
try.c:9:5: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
int r = IN6_IS_ADDR_V4MAPPED((&sin6.sin6_addr));
^
try.c:9:5: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
try.c:9:5: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
----------------------------------------------------------------
This is on FreeBSD 9.1-RELEASE amd64.
/usr/include/netinet6/in6.h contains:
/*
* Mapped
*/
#define IN6_IS_ADDR_V4MAPPED(a) \
((*(const u_int32_t *)(const void *)(&(a)->s6_addr[0]) == 0) && \
(*(const u_int32_t *)(const void *)(&(a)->s6_addr[4]) == 0) && \
(*(const u_int32_t *)(const void *)(&(a)->s6_addr[8]) ==
ntohl(0x0000ffff)))
So we indeed break C99/C11 aliasing rules here.
Pedantically speaking, it would also have to be htonl() instead of
ntohl() because the in6_addr is in network order, but it does not matter
to the machine because either maps to __bswap32() anyway.
The same in6.h also declares:
struct in6_addr {
union {
uint8_t __u6_addr8[16];
uint16_t __u6_addr16[8];
uint32_t __u6_addr32[4];
} __u6_addr; /* 128-bit IP6 address */
};
Which would appear to open up an alias-safe way (sanctioned by the C
standard, access through union containing the type) to reimplement the
macro, which also makes the GCC 4.8 warning go away and is far more
readable:
/*
* Mapped
*/
#define IN6_IS_ADDR_V4MAPPED(a) \
((a)->__u6_addr.__u6_addr32[0] == 0 && \
(a)->__u6_addr.__u6_addr32[1] == 0 && \
(a)->__u6_addr.__u6_addr16[2] == htonl(0x0000ffff))
Similar considerations apply to the other IN6_IS_ADDR_* macros.
Now, what do we do?
Can we get these fixed in a reasonable timeframe?
To whom, or where, would I submit a patch for all the macros so that it
actually gets committed to HEAD and MFC'd to /9 and /8?
Do we have unit tests for these macros? Should we add some?
Best
Matthias
(I don't have src commit permission.)
-- NOTE -- Please Cc: me on replies, I am not subscribed to freebsd-net.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
