Hm... Okay, I'm mistaken then.  I guess it doesn't matter.

Mike Frysinger <vap...@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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to