[PATCH] creds: suppress warning in get_cred

[PATCH] creds: suppress warning in get_cred

[Stephen Rothwell]

This is the usual way to force a conversion from a const pointer to a
non-const one and gets rid of this warning:

include/linux/cred.h: In function 'get_cred':
include/linux/cred.h:188: warning: passing argument 1 of 'get_new_cred' discards qualifiers from pointer target type

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/cred.h |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/include/linux/cred.h b/include/linux/cred.h
index 3282ee4..ed38227 100644
--- a/include/linux/cred.h
+++ b/include/linux/cred.h
@@ -12,6 +12,7 @@
 #ifndef _LINUX_CRED_H
 #define _LINUX_CRED_H
 
+#include <linux/types.h>
 #include <linux/capability.h>
 #include <linux/key.h>
 #include <asm/atomic.h>
@@ -185,7 +186,7 @@ static inline struct cred *get_new_cred(struct cred *cred)
  */
 static inline const struct cred *get_cred(const struct cred *cred)
 {
-	return get_new_cred((struct cred *) cred);
+	return get_new_cred((struct cred *)(uintptr_t)cred);
 }
 
 /**
-- 
1.6.0.5

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: [PATCH] creds: suppress warning in get_cred

[Hannes Eder]

On Mon, Jan 19, 2009 at 11:10 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> This is the usual way to force a conversion from a const pointer to a
> non-const one and gets rid of this warning:
>
> include/linux/cred.h: In function 'get_cred':
> include/linux/cred.h:188: warning: passing argument 1 of 'get_new_cred' discards qualifiers from pointer target type
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  include/linux/cred.h |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/cred.h b/include/linux/cred.h
> index 3282ee4..ed38227 100644
> --- a/include/linux/cred.h
> +++ b/include/linux/cred.h
> @@ -12,6 +12,7 @@
>  #ifndef _LINUX_CRED_H
>  #define _LINUX_CRED_H
>
> +#include <linux/types.h>
>  #include <linux/capability.h>
>  #include <linux/key.h>
>  #include <asm/atomic.h>
> @@ -185,7 +186,7 @@ static inline struct cred *get_new_cred(struct cred *cred)
>  */
>  static inline const struct cred *get_cred(const struct cred *cred)
>  {
> -       return get_new_cred((struct cred *) cred);
> +       return get_new_cred((struct cred *)(uintptr_t)cred);
>  }
>
>  /**

This is most likly a compiler bug, see

http://lkml.org/lkml/2008/11/20/441 and followups.

-Hannes

Re: [PATCH] creds: suppress warning in get_cred

[Stephen Rothwell]

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

Hi Hannes,

On Mon, 19 Jan 2009 12:03:44 +0100 "Hannes Eder" <hannes@hanneseder.net> wrote:
>
> This is most likly a compiler bug, see
> 
> http://lkml.org/lkml/2008/11/20/441 and followups.

Thanks.  Time for a new cross compiler. :-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] creds: suppress warning in get_cred

[David Howells]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> +	return get_new_cred((struct cred *)(uintptr_t)cred);

That should probably be 'unsigned long' within the kernel.  This is also a
compiler bug, but I think we can live with this fix.

David

Re: [PATCH] creds: suppress warning in get_cred

[Stephen Rothwell]

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

Hi David,

On Mon, 19 Jan 2009 12:29:31 +0000 David Howells <dhowells@redhat.com> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > +	return get_new_cred((struct cred *)(uintptr_t)cred);
> 
> That should probably be 'unsigned long' within the kernel.  This is also a
> compiler bug, but I think we can live with this fix.

We do have uintptr_t inside the kernel (it is typedeffed to unsigned
long) but I used it explicitly because its type is defined to be large
enough to store any pointer.

However, I have also verified that using a newer compiler (4.3.2 in my
case) makes the warning go away as Hannes Eder pointed out when
mentioning his earlier patch.

So, your choice.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] creds: suppress warning in get_cred

[Hannes Eder]

On Mon, Jan 19, 2009 at 3:52 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi David,
>
> On Mon, 19 Jan 2009 12:29:31 +0000 David Howells <dhowells@redhat.com> wrote:
>>
>> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> > +   return get_new_cred((struct cred *)(uintptr_t)cred);
>>
>> That should probably be 'unsigned long' within the kernel.  This is also a
>> compiler bug, but I think we can live with this fix.
>
> We do have uintptr_t inside the kernel (it is typedeffed to unsigned
> long) but I used it explicitly because its type is defined to be large
> enough to store any pointer.

When working around this compiler bug would it be better to do it like this:

+     return get_new_cred((struct cred *)(void *)cred);

instead of relying on the size of a pointer and using an large enough
integer data type?

Maybe would should just add a comment, to note that if such a warning
is issued, that
this is a compiler bug.

Or disable the warning for this region, but as far as I know gcc _does
not_ have this feature yet.

> However, I have also verified that using a newer compiler (4.3.2 in my
> case) makes the warning go away as Hannes Eder pointed out when
> mentioning his earlier patch.

Hannes

Re: [PATCH] creds: suppress warning in get_cred

[David Howells]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> We do have uintptr_t inside the kernel (it is typedeffed to unsigned
> long) but I used it explicitly because its type is defined to be large
> enough to store any pointer.

I believe that within the kernel, unsigned long is guaranteed to be the same
size as a pointer; so much code will break if this is not true.

> However, I have also verified that using a newer compiler (4.3.2 in my
> case) makes the warning go away as Hannes Eder pointed out when
> mentioning his earlier patch.
> 
> So, your choice.

I don't mind you putting the cast in, but I'd prefer the cast to be via
unsigned long, and I think it should have a comment to indicate why the extra
cast is necessary.

David