[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <B3C8EEBF-71FB-4169-8ED7-7C4A410BBEE1@mac.com>
Date: Wed, 27 Jun 2007 18:30:52 -0400
From: Kyle Moffett <mrmacman_g4@....com>
To: Adrian Bunk <bunk@...sta.de>
Cc: LKML Kernel <linux-kernel@...r.kernel.org>,
David Woodhouse <dwmw2@...radead.org>, david@...g.hm,
linux-arch@...r.kernel.org
Subject: Re: Userspace compiler support of "long long"
On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote:
> AFAIR the Intel compiler claims to be gcc.
>
> But these are by far not the only C compilers under Linux, and the
> more important points are:
>
> Is there any userspace Linux compiler that does not support "long
> long"?
Don't know, but I'd guess not.
> If yes, is there any other way to tell that something is a 64bit
> int on 32bit architectures?
Not that I know of. Probably the straight #else conditional is OK.
We should also merge up the types since *EVERY* linux architecture
has these same types:
typedef signed char __s8;
typedef unsigned char __u8;
typedef signed short __s16;
typedef unsigned short __u16;
typedef signed int __s32;
typedef unsigned int __u32;
Then all 64-bit archs have:
typedef signed long __s64;
typedef unsigned long __u64;
While all 32-bit archs have:
typedef signed long long __s64;
typedef unsigned long long __u64;
The only trick is if you care about building 32-bit compat code using
64-bit linux kernel headers. In that case we should probably just
make all archs use "long long" for their 64-bit integers, unless
there's some platform I'm not remembering where "long long" is 128-
bits or bigger. The other benefit is that people could then just use
the printf format "%llu" for 64-bit integers instead of having to
conditionalize it all over the place.
I'm working on a patch now.
Cheers,
Kyle Moffett
-
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/
Powered by blists - more mailing lists