lkml.org 
[lkml]   [2013]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] x86: make stat/statfs 64-bit for x86_64 kernels
From
Date
Hm... Okay, I'm mistaken then.  I guess it doesn't matter.

Mike Frysinger <vapier@gentoo.org> wrote:

>On Thursday 09 May 2013 00:18:15 H. Peter Anvin wrote:
>> On 05/08/2013 09:08 PM, Mike Frysinger wrote:
>> > On Thursday 09 May 2013 00:04:03 H. Peter Anvin wrote:
>> >> On 05/08/2013 09:00 PM, Mike Frysinger wrote:
>> >>> When including these headers in the x32 ABI, the structs get
>> >>> declared with 32bit sizes which is incorrect. Use long long
>> >>> and such to make it work both with x32 and x86_64.
>> >>
>> >> I'm not sure if it is okay to change the types, even within the
>> >> same size. Perhaps use __u64/__s64?
>> >
>> > sorry, i don't follow. changing types isn't ok (unsigned long to
>> > unsigned long long), but changing to __u64 is ok (unsigned long to
>> > __u64 which is typedefed to unsigned long long) ?
>> >
>> > i don't have a problem using __u64/__s64, i just don't understand
>> > your logic.
>>
>> In userspace, __u64 is often defined as "unsigned long" on 64 bits.
>
>my tests would seem to indicate otherwise, at least for x86:
>$ gcc -E - <<<"#include <linux/types.h>" | grep '__u64;'
>__extension__ typedef unsigned long long __u64;
>
>$ gcc -m32 -E - <<<"#include <linux/types.h>" | grep '__u64;'
>__extension__ typedef unsigned long long __u64;
>
>$ gcc -mx32 -E - <<<"#include <linux/types.h>" | grep '__u64;'
>__extension__ typedef unsigned long long __u64;
>
>and doing a printf("%i\n", sizeof(__u64)) shows 8 for each of the above
>builds
>-mike

--
Sent from my mobile phone. Please excuse brevity and lack of formatting.


\
 
 \ /
  Last update: 2013-05-09 08:01    [W:0.079 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site