From: Randy Dunlap <randy.dunlap@oracle.com>
To: Kyle Moffett <mrmacman_g4@mac.com>
Cc: Adrian Bunk <bunk@stusta.de>,
LKML Kernel <linux-kernel@vger.kernel.org>,
David Woodhouse <dwmw2@infradead.org>,
david@lang.hm, linux-arch@vger.kernel.org
Subject: Re: Userspace compiler support of "long long"
Date: Wed, 27 Jun 2007 16:16:48 -0700 [thread overview]
Message-ID: <20070627161648.52d3786d.randy.dunlap@oracle.com> (raw)
In-Reply-To: <20070627155715.60ebc48f.randy.dunlap@oracle.com>
On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote:
> On Wed, 27 Jun 2007 18:30:52 -0400 Kyle Moffett wrote:
>
> > 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.
>
> LDD3 ch. 11 says that long on Sparc64 is 32 bits.
> Same for "ppc" (don't know which power* arch. they mean by that).
Hm, I suppose that table only applies to userspace, not kernel...
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
next prev parent reply other threads:[~2007-06-27 23:22 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-21 22:32 Linux Kernel include files Joerg Schilling
2007-06-21 23:25 ` david
2007-06-21 23:38 ` Joerg Schilling
2007-06-22 3:38 ` David Woodhouse
2007-06-22 5:18 ` H. Peter Anvin
2007-06-22 15:00 ` Adrian Bunk
2007-06-26 15:26 ` H. Peter Anvin
2007-06-27 1:32 ` Kyle Moffett
2007-06-27 15:40 ` Adrian Bunk
2007-06-27 15:52 ` Joerg Schilling
2007-06-27 15:59 ` Robert P. J. Day
2007-06-27 17:32 ` Userspace compiler support of "long long" Adrian Bunk
2007-06-27 22:30 ` Kyle Moffett
2007-06-27 22:57 ` Randy Dunlap
2007-06-27 23:16 ` Randy Dunlap [this message]
2007-06-28 2:12 ` Geert Uytterhoeven
2007-06-28 6:50 ` Jan Engelhardt
2007-06-28 11:34 ` Geert Uytterhoeven
2007-06-28 11:36 ` David Woodhouse
2007-06-28 12:20 ` Kyle Moffett
2007-06-28 3:06 ` Kyle McMartin
2007-06-28 0:30 ` Andi Kleen
2007-06-28 11:42 ` Kyle Moffett
2007-06-28 3:57 ` Matthew Wilcox
2007-06-28 11:53 ` Kyle Moffett
2007-06-28 12:08 ` Jakub Jelinek
2007-06-28 12:18 ` Kyle Moffett
2007-06-28 4:03 ` H. Peter Anvin
2007-06-28 10:26 ` Harald Arnesen
2007-06-28 10:44 ` Joerg Schilling
2007-06-28 12:11 ` Kyle Moffett
2007-06-28 15:31 ` Mark Brown
2007-06-28 4:02 ` Linux Kernel include files H. Peter Anvin
2007-06-25 15:17 ` Joerg Schilling
2007-06-25 15:27 ` David Woodhouse
2007-06-25 18:04 ` Harald Arnesen
2007-06-25 20:26 ` Joerg Schilling
2007-06-25 20:32 ` David Woodhouse
2007-06-25 21:43 ` Harald Arnesen
2007-06-25 21:48 ` Harald Arnesen
2007-06-25 21:49 ` Joerg Schilling
2007-06-25 22:30 ` Harald Arnesen
2007-06-25 22:42 ` Joerg Schilling
2007-06-21 23:59 ` Arnd Bergmann
2007-06-25 15:06 ` Joerg Schilling
2007-06-25 16:00 ` david
2007-06-25 14:48 ` Joerg Schilling
2007-06-21 23:47 ` Arjan van de Ven
2007-06-25 14:53 ` Joerg Schilling
2007-06-25 15:26 ` Arjan van de Ven
2007-06-25 15:27 ` Robert P. J. Day
2007-06-25 20:18 ` Sam Ravnborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070627161648.52d3786d.randy.dunlap@oracle.com \
--to=randy.dunlap@oracle.com \
--cc=bunk@stusta.de \
--cc=david@lang.hm \
--cc=dwmw2@infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mrmacman_g4@mac.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).