linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 ***

  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).