2009-10-13 07:37:38

by Leonidas .

[permalink] [raw]
Subject: Using intptr_t and uintptr_t in Kernel

Hello List,

I know variants of this questions have been asked on this list before,
but I could not
find a thread where a conclusion was reached, most of the time
responses were { I don't care,
developer's choice, might be in future } and variations thereof. But
one thing was clear
that do not mix userspace and kernel space data types.

Currently, I am porting a user space application to kernel, this app
uses intptr_t data type.

A look at linux/types.h shows that,

typedef unsigned long uintptr_t;

but intptr_t is not defined at all. Also, isn't above definition
incorrect? Since the whole idea
behind uintptr_t is to store pointer in a int sized variable, are we
not assuming here that

sizeof(int) = sizeof(unsigned long ) on all archs? I have not worked
on all archs on which Linux
runs, but if that is the case then above definition is correct.

After looking at stdint.h (which is not available for kernel),

typedef __s32 intptr_t;
typedef __u32 uintptr_t;

sounds more appropriate. Please CMIIW.

-Leo.


2009-10-13 08:50:04

by Mikael Pettersson

[permalink] [raw]
Subject: Re: Using intptr_t and uintptr_t in Kernel

Leonidas . writes:
> I know variants of this questions have been asked on this list before,
> but I could not
> find a thread where a conclusion was reached, most of the time
> responses were { I don't care,
> developer's choice, might be in future } and variations thereof. But
> one thing was clear
> that do not mix userspace and kernel space data types.
>
> Currently, I am porting a user space application to kernel, this app
> uses intptr_t data type.
>
> A look at linux/types.h shows that,
>
> typedef unsigned long uintptr_t;
>
> but intptr_t is not defined at all. Also, isn't above definition
> incorrect?

No, it's correct because Linux requires sizeof(void*) == sizeof(long).

> Since the whole idea
> behind uintptr_t is to store pointer in a int sized variable,

uintptr_t will use _some_ integer type, not necessarily 'int'.

If ISO C said 'int' there would be no need for {,u}intptr_t.

> are we
> not assuming here that
>
> sizeof(int) = sizeof(unsigned long ) on all archs?

No, see above.

2009-10-13 08:58:40

by Leonidas .

[permalink] [raw]
Subject: Re: Using intptr_t and uintptr_t in Kernel

On Tue, Oct 13, 2009 at 2:19 PM, Mikael Pettersson <[email protected]> wrote:
> Leonidas . writes:
> ?> I know variants of this questions have been asked on this list before,
> ?> but I could not
> ?> find a thread where a conclusion was reached, most of the time
> ?> responses were { I don't care,
> ?> developer's choice, might be in future } and variations thereof. But
> ?> one thing was clear
> ?> that do not mix userspace and kernel space data types.
> ?>
> ?> Currently, I am porting a user space application to kernel, this app
> ?> uses intptr_t data type.
> ?>
> ?> A look at linux/types.h shows that,
> ?>
> ?> typedef unsigned long ? ? ? ? ? uintptr_t;
> ?>
> ?> but intptr_t is not defined at all. Also, isn't above definition
> ?> incorrect?
>
> No, it's correct because Linux requires sizeof(void*) == sizeof(long).
>
> ?> Since the whole idea
> ?> behind uintptr_t is to store pointer in a int sized variable,
>
> uintptr_t will use _some_ integer type, not necessarily 'int'.
>
> If ISO C said 'int' there would be no need for {,u}intptr_t.
>
> ?> are we
> ?> not assuming here that
> ?>
> ?> sizeof(int) = sizeof(unsigned long ) on all archs?
>
> No, see above.
>

Thanks, for the response, but frankly I am still confused.
Let me recollect my thoughts in more concise manner.


User space documentation for C99, http://linux.die.net/man/3/intptr_t says,

typedef unsigned int uint16_t
typedef uint16_t uintptr_t

and http://lxr.linux.no/#linux+v2.6.31/include/linux/types.h#L41 says,

typedef unsigned short __u16;
typedef __u16 uint16_t;

i.e. kernel space mean 16 bits when it says u16 but gcc does not mean
the same thing.
So if a programmer meant uintptr_t in userspace he means store the
pointer in a datatype
which is as big as uint16_t i.e. unsigned int. So hold the pointer in
an unsigned int.

In kernel space if we go by the data type definitions, we would get a
pointer of size __u16
which is an unsigned short, the programmer did not intend this, right?


-Leo.

2009-10-13 11:47:49

by Mikael Pettersson

[permalink] [raw]
Subject: Re: Using intptr_t and uintptr_t in Kernel

Leonidas . writes:
> > ?> typedef unsigned long ? ? ? ? ? uintptr_t;
> > ?>
> > ?> but intptr_t is not defined at all. Also, isn't above definition
> > ?> incorrect?
> >
> > No, it's correct because Linux requires sizeof(void*) == sizeof(long).
> >
> > ?> Since the whole idea
> > ?> behind uintptr_t is to store pointer in a int sized variable,
> >
> > uintptr_t will use _some_ integer type, not necessarily 'int'.
> >
> > If ISO C said 'int' there would be no need for {,u}intptr_t.
> >
> > ?> are we
> > ?> not assuming here that
> > ?>
> > ?> sizeof(int) = sizeof(unsigned long ) on all archs?
> >
> > No, see above.
> >
>
> Thanks, for the response, but frankly I am still confused.
> Let me recollect my thoughts in more concise manner.
>
>
> User space documentation for C99, http://linux.die.net/man/3/intptr_t says,
>
> typedef unsigned int uint16_t
> typedef uint16_t uintptr_t

That's based on what C99 states, but it's not the definition of uintptr_t
but a specification of the minimal size of that type. The page you're
referring to fails to mention that.

Anyway, this is not an issue with the kernel. Please direct C questions
to a C-specific forum, like comp.std.c. Or google n1124.pdf and read that.