All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.