linux-kernel - Using intptr_t and uintptr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <f22d86810910130037x48cac5c1s8928a6ff49dda381@mail.gmail.com>
Date:	Tue, 13 Oct 2009 13:07:00 +0530
From:	"Leonidas ." <leonidas137@...il.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/