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 <[email protected]>
---
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 [email protected]
http://www.canb.auug.org.au/~sfr/
On Mon, Jan 19, 2009 at 11:10 AM, Stephen Rothwell <[email protected]> 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 <[email protected]>
> ---
> 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
Stephen Rothwell <[email protected]> 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
Hi Hannes,
On Mon, 19 Jan 2009 12:03:44 +0100 "Hannes Eder" <[email protected]> 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 [email protected]
http://www.canb.auug.org.au/~sfr/
Hi David,
On Mon, 19 Jan 2009 12:29:31 +0000 David Howells <[email protected]> wrote:
>
> Stephen Rothwell <[email protected]> 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 [email protected]
http://www.canb.auug.org.au/~sfr/
On Mon, Jan 19, 2009 at 3:52 PM, Stephen Rothwell <[email protected]> wrote:
> Hi David,
>
> On Mon, 19 Jan 2009 12:29:31 +0000 David Howells <[email protected]> wrote:
>>
>> Stephen Rothwell <[email protected]> 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
Stephen Rothwell <[email protected]> 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