Re: [PATCH] net: clean up some sparse endianness warnings in ipv6.h

[Jeff Layton <jeff.layton@primarydata.com>]

On Mon, 14 Jul 2014 08:25:46 -0400
Jeff Layton <jlayton@primarydata.com> wrote:

> sparse is throwing warnings when building sunrpc modules due to some
> endianness shenanigans in ipv6.h. Sprinkle some endianness fixups to
> silence them. These should all get fixed up at compile time, so I don't
> think this will add any extra work to be done at runtime.
> 
> Signed-off-by: Jeff Layton <jlayton@primarydata.com>
> ---
>  include/net/ipv6.h | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/net/ipv6.h b/include/net/ipv6.h
> index 574337fe72dd..5ed2c24fe950 100644
> --- a/include/net/ipv6.h
> +++ b/include/net/ipv6.h
> @@ -557,9 +557,9 @@ static inline u32 __ipv6_addr_jhash(const struct in6_addr *a, const u32 initval)
>  static inline bool ipv6_addr_loopback(const struct in6_addr *a)
>  {
>  #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && BITS_PER_LONG == 64
> -	const unsigned long *ul = (const unsigned long *)a;
> +	const __be64 *be = (const __be64 *)a;
>  
> -	return (ul[0] | (ul[1] ^ cpu_to_be64(1))) == 0UL;
> +	return (be[0] | (be[1] ^ cpu_to_be64(1))) == cpu_to_be64(0UL);
>  #else
>  	return (a->s6_addr32[0] | a->s6_addr32[1] |
>  		a->s6_addr32[2] | (a->s6_addr32[3] ^ htonl(1))) == 0;
> @@ -570,11 +570,11 @@ static inline bool ipv6_addr_v4mapped(const struct in6_addr *a)
>  {
>  	return (
>  #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && BITS_PER_LONG == 64
> -		*(__be64 *)a |
> +		(*(__be64 *)a != cpu_to_be64(0)) |
>  #else
> -		(a->s6_addr32[0] | a->s6_addr32[1]) |
> +		((a->s6_addr32[0] | a->s6_addr32[1]) != cpu_to_be32(0)) |
>  #endif
> -		(a->s6_addr32[2] ^ htonl(0x0000ffff))) == 0UL;
> +		((a->s6_addr32[2] ^ htonl(0x0000ffff)) == cpu_to_be32(0)));
>  }
>  
>  /*

Oof. I think I had the ipv6_addr_v4mapped changes wrong before due to
misreading the code. The existing code basically takes the different
values, does a bunch of bitwise operations on them and then compares
the result to 0.

My patch had it doing more than one comparison. I've got a fixed
version, but it does mean that we need to use a __force cast in one
place. I'll resend once I've tested it our some more.

Sorry for the noise!
-- 
Jeff Layton <jlayton@primarydata.com>