diff mbox

include/linux/skbuff.h: using '0xffff' instead of '~0U'

Message ID 51A6EBC5.7040601@asianux.com
State Not Applicable, archived
Delegated to: David Miller
Headers show

Commit Message

Chen Gang May 30, 2013, 6:03 a.m. UTC
Both 'transport_header' and 'mac_header' are u16, which are never equal
to '~0U'.

So need use '0xffff' instead of '~0U'.

The related warning (with EXTRA_CFLAGS=-W ARCH=m68k for allmodconfig)
  include/linux/skbuff.h:1587:2: warning: comparison is always true due to limited range of data type [-Wtype-limits]
  ...


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 include/linux/skbuff.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

Comments

Chen Gang May 30, 2013, 9:55 a.m. UTC | #1
It seems a good idea to "fgrep -rn '~0U'" all source code, and check
each one by one.

:-)


On 05/30/2013 02:03 PM, Chen Gang wrote:
> 
> Both 'transport_header' and 'mac_header' are u16, which are never equal
> to '~0U'.
> 
> So need use '0xffff' instead of '~0U'.
> 
> The related warning (with EXTRA_CFLAGS=-W ARCH=m68k for allmodconfig)
>   include/linux/skbuff.h:1587:2: warning: comparison is always true due to limited range of data type [-Wtype-limits]
>   ...
> 
> 
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
>  include/linux/skbuff.h |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 2e0ced1..03ba058 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -1581,7 +1581,7 @@ static inline void skb_set_inner_mac_header(struct sk_buff *skb,
>  }
>  static inline bool skb_transport_header_was_set(const struct sk_buff *skb)
>  {
> -	return skb->transport_header != ~0U;
> +	return skb->transport_header != 0xffff;
>  }
>  
>  static inline unsigned char *skb_transport_header(const struct sk_buff *skb)
> @@ -1624,7 +1624,7 @@ static inline unsigned char *skb_mac_header(const struct sk_buff *skb)
>  
>  static inline int skb_mac_header_was_set(const struct sk_buff *skb)
>  {
> -	return skb->mac_header != ~0U;
> +	return skb->mac_header != 0xffff;
>  }
>  
>  static inline void skb_reset_mac_header(struct sk_buff *skb)
>
Ben Hutchings May 30, 2013, 3:30 p.m. UTC | #2
On Thu, 2013-05-30 at 14:03 +0800, Chen Gang wrote:
> Both 'transport_header' and 'mac_header' are u16, which are never equal
> to '~0U'.
> 
> So need use '0xffff' instead of '~0U'.

...and give this magic number a name?

Ben.

> The related warning (with EXTRA_CFLAGS=-W ARCH=m68k for allmodconfig)
>   include/linux/skbuff.h:1587:2: warning: comparison is always true due to limited range of data type [-Wtype-limits]
>   ...
> 
> 
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
>  include/linux/skbuff.h |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 2e0ced1..03ba058 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -1581,7 +1581,7 @@ static inline void skb_set_inner_mac_header(struct sk_buff *skb,
>  }
>  static inline bool skb_transport_header_was_set(const struct sk_buff *skb)
>  {
> -	return skb->transport_header != ~0U;
> +	return skb->transport_header != 0xffff;
>  }
>  
>  static inline unsigned char *skb_transport_header(const struct sk_buff *skb)
> @@ -1624,7 +1624,7 @@ static inline unsigned char *skb_mac_header(const struct sk_buff *skb)
>  
>  static inline int skb_mac_header_was_set(const struct sk_buff *skb)
>  {
> -	return skb->mac_header != ~0U;
> +	return skb->mac_header != 0xffff;
>  }
>  
>  static inline void skb_reset_mac_header(struct sk_buff *skb)
Andy Shevchenko May 31, 2013, 9:05 p.m. UTC | #3
On Thu, May 30, 2013 at 9:03 AM, Chen Gang <gang.chen@asianux.com> wrote:
>
> Both 'transport_header' and 'mac_header' are u16, which are never equal
> to '~0U'.
>
> So need use '0xffff' instead of '~0U'.

Why not "(u16)~0" ?
Or even better "!= USHORT_MAX"?

Or mac_header + 1 == 0, though it less clear.

--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Chen Gang June 3, 2013, 8:52 a.m. UTC | #4
On 05/30/2013 11:30 PM, Ben Hutchings wrote:
> On Thu, 2013-05-30 at 14:03 +0800, Chen Gang wrote:
>> > Both 'transport_header' and 'mac_header' are u16, which are never equal
>> > to '~0U'.
>> > 
>> > So need use '0xffff' instead of '~0U'.
> ..and give this magic number a name?

It sounds a good idea. I will check which name is suitable for it, then
send patch v2, and please help to check it, too.


Thanks.
Chen Gang June 3, 2013, 9:23 a.m. UTC | #5
On 06/01/2013 05:05 AM, Andy Shevchenko wrote:
> On Thu, May 30, 2013 at 9:03 AM, Chen Gang <gang.chen@asianux.com> wrote:
>> >
>> > Both 'transport_header' and 'mac_header' are u16, which are never equal
>> > to '~0U'.
>> >
>> > So need use '0xffff' instead of '~0U'.
> Why not "(u16)~0" ?
> Or even better "!= USHORT_MAX"?
> 
> Or mac_header + 1 == 0, though it less clear.

It seems they are just the same as '0xffff' (are all 'magic' number).

We'd better to give a meaningful name to it just like Ben said.


Thanks.
Andy Shevchenko June 3, 2013, 10:14 a.m. UTC | #6
On Mon, Jun 3, 2013 at 12:23 PM, Chen Gang <gang.chen@asianux.com> wrote:
> On 06/01/2013 05:05 AM, Andy Shevchenko wrote:

>> Why not "(u16)~0" ?
> We'd better to give a meaningful name to it just like Ben said.

Yeah, you could give a name, though I don't see this needs for
constants like (u16)~0. It's a usual way to mark some values
uninitialized.
Just an example from kernel:

        /* This is limited by 16 bit "slot" numbers,
         * and by available on-disk context storage.
         *
         * Also (u16)~0 is special (denotes a "free" extent).

--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Chen Gang June 3, 2013, 10:51 a.m. UTC | #7
On 06/03/2013 06:14 PM, Andy Shevchenko wrote:
> On Mon, Jun 3, 2013 at 12:23 PM, Chen Gang <gang.chen@asianux.com> wrote:
>> On 06/01/2013 05:05 AM, Andy Shevchenko wrote:
> 
>>> Why not "(u16)~0" ?
>> We'd better to give a meaningful name to it just like Ben said.
> 
> Yeah, you could give a name, though I don't see this needs for
> constants like (u16)~0. It's a usual way to mark some values
> uninitialized.
> Just an example from kernel:
> 
>         /* This is limited by 16 bit "slot" numbers,
>          * and by available on-disk context storage.
>          *
>          * Also (u16)~0 is special (denotes a "free" extent).
> 

After "fgrep -rn 'u16' * | fgrep '~0'", it seems better to define a
meaningful macro for it (e.g. "#define SKB_HEADER_WAS_UNSET    0xffff").


Thanks.
diff mbox

Patch

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 2e0ced1..03ba058 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1581,7 +1581,7 @@  static inline void skb_set_inner_mac_header(struct sk_buff *skb,
 }
 static inline bool skb_transport_header_was_set(const struct sk_buff *skb)
 {
-	return skb->transport_header != ~0U;
+	return skb->transport_header != 0xffff;
 }
 
 static inline unsigned char *skb_transport_header(const struct sk_buff *skb)
@@ -1624,7 +1624,7 @@  static inline unsigned char *skb_mac_header(const struct sk_buff *skb)
 
 static inline int skb_mac_header_was_set(const struct sk_buff *skb)
 {
-	return skb->mac_header != ~0U;
+	return skb->mac_header != 0xffff;
 }
 
 static inline void skb_reset_mac_header(struct sk_buff *skb)