[PATCH] [TRIVIAL] "unsigned char"/"char" consistency?

[PATCH] [TRIVIAL] "unsigned char"/"char" consistency?

[Bart Samwel]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

Hi there,

I was just nosing around and I noticed a minor inconsistency in the 
usage of unsigned chars in skbuff push/pull functions. Almost all of 
these functions return unsigned chars, but there are two that return 
regular chars. Of course, this might be intentional, but AFAICS it 
probably isn't. If nobody has a reason why this must be like this, I 
suggest changing those two functions to return unsigned char as well. 
I've attached a patch that does this, it's against 2.6.2-rc1.

-- Bart

[-- Attachment #2: unsigned_char_skbuff_pull.patch --]
[-- Type: text/x-patch, Size: 866 bytes --]

diff -Naur linux-2.6.2-rc1/include/linux/skbuff.h linux-2.6.2-rc1-withunsigneds/include/linux/skbuff.h
--- linux-2.6.2-rc1/include/linux/skbuff.h	2004-01-09 07:59:44.000000000 +0100
+++ linux-2.6.2-rc1-withunsigneds/include/linux/skbuff.h	2004-01-24 16:40:42.000000000 +0100
@@ -871,7 +871,7 @@
 	return skb->data;
 }
 
-static inline char *__skb_pull(struct sk_buff *skb, unsigned int len)
+static inline unsigned char *__skb_pull(struct sk_buff *skb, unsigned int len)
 {
 	skb->len -= len;
 	BUG_ON(skb->len < skb->data_len);
@@ -895,7 +895,7 @@
 
 extern unsigned char *__pskb_pull_tail(struct sk_buff *skb, int delta);
 
-static inline char *__pskb_pull(struct sk_buff *skb, unsigned int len)
+static inline unsigned char *__pskb_pull(struct sk_buff *skb, unsigned int len)
 {
 	if (len > skb_headlen(skb) &&
 	    !__pskb_pull_tail(skb, len-skb_headlen(skb)))

Re: [PATCH] [TRIVIAL] "unsigned char"/"char" consistency?

[David S. Miller]

   From: Bart Samwel <bart@samwel.tk>
   Date: Sat, 24 Jan 2004 18:05:57 +0100

   I was just nosing around and I noticed a minor inconsistency in the 
   usage of unsigned chars in skbuff push/pull functions. Almost all of 
   these functions return unsigned chars, but there are two that return 
   regular chars. Of course, this might be intentional, but AFAICS it 
   probably isn't. If nobody has a reason why this must be like this, I 
   suggest changing those two functions to return unsigned char as well. 
   I've attached a patch that does this, it's against 2.6.2-rc1.

Patch applied, thanks Bart.