https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105884
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Definitely an aliasing bug:
((uint64_t*)result->s6_addr)[0] = ((uint64_t*)a->s6_addr)[0] &
((uint64_t*)b->s6_addr)[0];
((uint64_t*)result->s6_addr)[1] = ((uint64_t*)a->s6_addr)[1] &
((uint64_t*)b->s6_addr)[1];
Even their "fix" to use uint32_t instead is wrong.
With glibc the s6_addr array has type uint8_t[16] so there are no uint64_t (or
uint32_t) objects there.
With _GNU_SOURCE or _DEFAULT_SOURCE (formerly _BSD_SOURCE) defined, there is a
s6_addr32 member which can be used to type-pun the s6_addr array as 32-bit
values.
The portable solution is to memcpy from s6_addr to uint64_t[2], perform the
bitwise AND ops on the uint64_t objects, and then memcpy back to s6_addr.
