This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -Wstrict-aliasing in 2.95/6?
> Someone said `memcpy' in general doesn't have aliasing problems, and in
> fact `memcpy' is often the _only_ safe way to access the bit pattern of
> one type as another. (The union suggestion is apparently specific
> to a quirk of GCC's implementation).
That's because the 'right' memcpy implementation operates on char*.
> So it's Linux' implementation of __constant_memcpy that has an aliasing
> bug? I guess that one can be fixed if there's a fix.
There is no fix. If you use int* to do the copy, you lose because it
is wrong. If you use char*, you use because it is inefficient.
People have been trying to use __builtin_memcpy instead. That works
fine, but the approach dies when it comes to __builtin_memset which is
only __builtin_bzero.
> >#define TCP_IPV4_MATCH(__sk, __cookie, __saddr, __daddr, __ports, __dif)\
> > (((*((__u64 *)&((__sk)->daddr)))== (__cookie)) && \
> > ((*((__u32 *)&((__sk)->dport)))== (__ports)) && \
> > (!((__sk)->bound_dev_if) || ((__sk)->bound_dev_if == (__dif))))
[...]
> Apparently this occurs a lot in the kernel.
Ok. This is a conversion between different pointer-to-integral-types.
I forgot: Under the your most recent proposal; would you warn here?
Regards,
Martin