linux-kernel - Re: Userspace compiler support of "long long"

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: <88515A48-E155-48A7-8EAE-095B080EAFE4@mac.com>
Date:	Thu, 28 Jun 2007 07:42:46 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Andi Kleen <ak@...e.de>
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 Jun 27, 2007, at 20:30:42, Andi Kleen wrote:
> On Thursday 28 June 2007 00:30:52 Kyle Moffett wrote:
>> 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.
>
> Changing this will give you a zillion warnings for printk formats.

Why?  If this were a problem then we'd be getting a zillion warnings  
*now* from all the 32-bit archs (which already use "long long" for 64- 
bit.  This would actually make it _easier_ to get the printk formats  
right, as you could always use %ull for 64-bit types without having  
to cast for 64-bit platforms.

This is another way to get around the "build 32-bit-compat userspace  
on 64-bit kernel headers" problem:  It tells GCC to use the  
"smallest" available type of the given size, which ends up being  
exactly the types we use now.  On the other hand, it only works for  
GCC which sort of ruins most of the reason for changing the types in  
the first place.

typedef   signed __s8  __attribute__((__mode__(__QI__)));
typedef unsigned __u8  __attribute__((__mode__(__QI__)));
typedef   signed __s16 __attribute__((__mode__(__HI__)));
typedef unsigned __u16 __attribute__((__mode__(__HI__)));
typedef   signed __s32 __attribute__((__mode__(__SI__)));
typedef unsigned __u32 __attribute__((__mode__(__SI__)));
typedef   signed __s64 __attribute__((__mode__(__DI__)));
typedef unsigned __u64 __attribute__((__mode__(__DI__)));

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/