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-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070627155715.60ebc48f.randy.dunlap@oracle.com>
Date:	Wed, 27 Jun 2007 15:57:15 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Kyle Moffett <mrmacman_g4@....com>
Cc:	Adrian Bunk <bunk@...sta.de>,
	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 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).

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ