[2.6 patch] asm-generic/int-ll64.h: always provide __{s,u}64

[2.6 patch] asm-generic/int-ll64.h: always provide __{s,u}64

[Adrian Bunk]

Several compilers offer "long long" without claiming to support C99.

Considering how frequent __s64/__u64 are used our userspace headers are 
anyway unusable without __s64/__u64 available.

Always offer __s64/__u64 to non-gcc non-C99 compilers - if they provide 
"long long" that makes the headers compiling and if they don't they are 
anyway screwed.

Signed-off-by: Adrian Bunk <bunk@kernel.org>

---
bd3028092483c517700a40c36ca264cedd0ff488 diff --git a/include/asm-generic/int-ll64.h b/include/asm-generic/int-ll64.h
index 2609489..f9bc9ac 100644
--- a/include/asm-generic/int-ll64.h
+++ b/include/asm-generic/int-ll64.h
@@ -26,7 +26,7 @@ typedef unsigned int __u32;
 #ifdef __GNUC__
 __extension__ typedef __signed__ long long __s64;
 __extension__ typedef unsigned long long __u64;
-#elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
+#else
 typedef __signed__ long long __s64;
 typedef unsigned long long __u64;
 #endif

Re: [2.6 patch] asm-generic/int-ll64.h: always provide __{s,u}64

[H. Peter Anvin]

Adrian Bunk wrote:
> Several compilers offer "long long" without claiming to support C99.
> 
> Considering how frequent __s64/__u64 are used our userspace headers are 
> anyway unusable without __s64/__u64 available.
> 
> Always offer __s64/__u64 to non-gcc non-C99 compilers - if they provide 
> "long long" that makes the headers compiling and if they don't they are 
> anyway screwed.
> 
> Signed-off-by: Adrian Bunk <bunk@kernel.org>

This makes sense to me (I did, however, not want to make that change 
part of the same changeset - one change at a time.)

The main reason for not just blindly using "long long" has to do with 
the use of gcc -ansi -pedantic in userspace, which is already taken care 
of by the use of __extension__ in the __GNUC__ clause.

Acked-by: H. Peter Anvin <hpa@zytor.com>

Re: [2.6 patch] asm-generic/int-ll64.h: always provide __{s,u}64

[Harvey Harrison]

On Mon, 2008-05-19 at 15:01 -0700, H. Peter Anvin wrote:
> Adrian Bunk wrote:
> > Several compilers offer "long long" without claiming to support C99.
> > 
> > Considering how frequent __s64/__u64 are used our userspace headers are 
> > anyway unusable without __s64/__u64 available.
> > 
> > Always offer __s64/__u64 to non-gcc non-C99 compilers - if they provide 
> > "long long" that makes the headers compiling and if they don't they are 
> > anyway screwed.
> > 
> > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> 
> This makes sense to me (I did, however, not want to make that change 
> part of the same changeset - one change at a time.)
> 
> The main reason for not just blindly using "long long" has to do with 
> the use of gcc -ansi -pedantic in userspace, which is already taken care 
> of by the use of __extension__ in the __GNUC__ clause.
> 

If it is going to be unconditionally offered, we could get rid of
__BYTEORDER_HAS_U64__ as a next step.  Unless there is something I've
missed.

Harvey

Re: [2.6 patch] asm-generic/int-ll64.h: always provide __{s,u}64

[H. Peter Anvin]

Harvey Harrison wrote:
> 
> If it is going to be unconditionally offered, we could get rid of
> __BYTEORDER_HAS_U64__ as a next step.  Unless there is something I've
> missed.
> 

That would be good, too.

	-hpa

Re: [2.6 patch] asm-generic/int-ll64.h: always provide __{s,u}64

[Adrian Bunk]

On Mon, May 19, 2008 at 03:27:28PM -0700, Harvey Harrison wrote:
> On Mon, 2008-05-19 at 15:01 -0700, H. Peter Anvin wrote:
> > Adrian Bunk wrote:
> > > Several compilers offer "long long" without claiming to support C99.
> > > 
> > > Considering how frequent __s64/__u64 are used our userspace headers are 
> > > anyway unusable without __s64/__u64 available.
> > > 
> > > Always offer __s64/__u64 to non-gcc non-C99 compilers - if they provide 
> > > "long long" that makes the headers compiling and if they don't they are 
> > > anyway screwed.
> > > 
> > > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> > 
> > This makes sense to me (I did, however, not want to make that change 
> > part of the same changeset - one change at a time.)
> > 
> > The main reason for not just blindly using "long long" has to do with 
> > the use of gcc -ansi -pedantic in userspace, which is already taken care 
> > of by the use of __extension__ in the __GNUC__ clause.
> > 
> 
> If it is going to be unconditionally offered, we could get rid of
> __BYTEORDER_HAS_U64__ as a next step.  Unless there is something I've
> missed.

Why do we need the byteorder headers in userspace at all?

> Harvey

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] asm-generic/int-ll64.h: always provide __{s,u}64

[H. Peter Anvin]

Adrian Bunk wrote:
>>>
>> If it is going to be unconditionally offered, we could get rid of
>> __BYTEORDER_HAS_U64__ as a next step.  Unless there is something I've
>> missed.
> 
> Why do we need the byteorder headers in userspace at all?
> 

Because Linux-specific software has depended on them for over 15 years 
(they are a much better API than anything POSIX provides.)  We can't 
just yank them, and so it's better if they actually work.

Yes, you can argue it should be glibc's job to provide them, but well, 
why duplicate work when we already have a nicely working set.

	-hpa

Re: [2.6 patch] asm-generic/int-ll64.h: always provide __{s,u}64

[Adrian Bunk]

On Mon, May 19, 2008 at 04:51:53PM -0700, H. Peter Anvin wrote:
> Adrian Bunk wrote:
>>>>
>>> If it is going to be unconditionally offered, we could get rid of
>>> __BYTEORDER_HAS_U64__ as a next step.  Unless there is something I've
>>> missed.
>>
>> Why do we need the byteorder headers in userspace at all?
>>
>
> Because Linux-specific software has depended on them for over 15 years  
> (they are a much better API than anything POSIX provides.)  We can't  
> just yank them, and so it's better if they actually work.
> 
> Yes, you can argue it should be glibc's job to provide them, but well,  
> why duplicate work when we already have a nicely working set.

The worst thing is how many CONFIG_'s they currently leak to userspace.

And e.g. the versions in the x86 header are therefore not the fastest 
ones (unless the userspace software #define's CONFIG_X86_BSWAP)...

> 	-hpa

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] asm-generic/int-ll64.h: always provide __{s,u}64

[H. Peter Anvin]

Adrian Bunk wrote:
> On Mon, May 19, 2008 at 04:51:53PM -0700, H. Peter Anvin wrote:
>> Adrian Bunk wrote:
>>>> If it is going to be unconditionally offered, we could get rid of
>>>> __BYTEORDER_HAS_U64__ as a next step.  Unless there is something I've
>>>> missed.
>>> Why do we need the byteorder headers in userspace at all?
>>>
>> Because Linux-specific software has depended on them for over 15 years  
>> (they are a much better API than anything POSIX provides.)  We can't  
>> just yank them, and so it's better if they actually work.
>>
>> Yes, you can argue it should be glibc's job to provide them, but well,  
>> why duplicate work when we already have a nicely working set.
> 
> The worst thing is how many CONFIG_'s they currently leak to userspace.
> 
> And e.g. the versions in the x86 header are therefore not the fastest 
> ones (unless the userspace software #define's CONFIG_X86_BSWAP)...
> 

This is a valid point.  This should be __i486__ for userspace, which is 
gcc's way to tell you if you're compiling with -march=i486.

	-hpa

Re: [2.6 patch] asm-generic/int-ll64.h: always provide __{s,u}64

[Adrian Bunk]

On Mon, May 19, 2008 at 05:17:31PM -0700, H. Peter Anvin wrote:
> Adrian Bunk wrote:
>> On Mon, May 19, 2008 at 04:51:53PM -0700, H. Peter Anvin wrote:
>>> Adrian Bunk wrote:
>>>>> If it is going to be unconditionally offered, we could get rid of
>>>>> __BYTEORDER_HAS_U64__ as a next step.  Unless there is something I've
>>>>> missed.
>>>> Why do we need the byteorder headers in userspace at all?
>>>>
>>> Because Linux-specific software has depended on them for over 15 
>>> years  (they are a much better API than anything POSIX provides.)  We 
>>> can't  just yank them, and so it's better if they actually work.
>>>
>>> Yes, you can argue it should be glibc's job to provide them, but 
>>> well,  why duplicate work when we already have a nicely working set.
>>
>> The worst thing is how many CONFIG_'s they currently leak to userspace.
>>
>> And e.g. the versions in the x86 header are therefore not the fastest  
>> ones (unless the userspace software #define's CONFIG_X86_BSWAP)...
>>
>
> This is a valid point.  This should be __i486__ for userspace, which is  
> gcc's way to tell you if you're compiling with -march=i486.

This doesn't help if you're compiling with e.g. -march=pentium

> 	-hpa

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] asm-generic/int-ll64.h: always provide __{s,u}64

[H. Peter Anvin]

Adrian Bunk wrote:
>>>
>> This is a valid point.  This should be __i486__ for userspace, which is  
>> gcc's way to tell you if you're compiling with -march=i486.
> 
> This doesn't help if you're compiling with e.g. -march=pentium
> 

Yes, it does.  -march=pentium defines __i486__ as well as __i586__, and 
so on.

	-hpa

Re: [2.6 patch] asm-generic/int-ll64.h: always provide __{s,u}64

[Adrian Bunk]

On Mon, May 19, 2008 at 06:16:29PM -0700, H. Peter Anvin wrote:
> Adrian Bunk wrote:
>>>>
>>> This is a valid point.  This should be __i486__ for userspace, which 
>>> is  gcc's way to tell you if you're compiling with -march=i486.
>>
>> This doesn't help if you're compiling with e.g. -march=pentium
>
> Yes, it does.  -march=pentium defines __i486__ as well as __i586__, and  
> so on.

$ cat test.c
#include <stdio.h>

int main()
{
#ifdef __i486__
  printf("foobarbaz\n");
#endif

  return 0;
}
$ gcc -O2 -march=i486 -Wall test.c; ./a.out
foobarbaz
$ gcc -O2 -march=pentium -Wall test.c; ./a.out
$ gcc --version
gcc (Debian 4.3.0-4) 4.3.1 20080501 (prerelease)
...
$ /usr/local/DIR/gcc-3.2.3/bin/gcc -O2 -march=i486 -Wall test.c; ./a.out
foobarbaz
$ /usr/local/DIR/gcc-3.2.3/bin/gcc -O2 -march=pentium -Wall test.c; ./a.out
$ /usr/local/DIR/gcc-3.2.3/bin/gcc --version
gcc (GCC) 3.2.3


> 	-hpa

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] asm-generic/int-ll64.h: always provide __{s,u}64

[H. Peter Anvin]

Adrian Bunk wrote:
> 
> $ cat test.c
> #include <stdio.h>
> 
> int main()
> {
> #ifdef __i486__
>   printf("foobarbaz\n");
> #endif
> 
>   return 0;
> }

*Groan* you're right.  Blitering idiots... they only present __i386__ 
and whatever *exact* CPU you have -march= for, which of course is a 
*CHANGING SET* (just __i486__, __i586__ and __i686__ isn't enough... 
they seem to also have __core2__, __k8__ and $DEITY knows what else.)

The only sensible way to handle that would be to centralize that 
knowledge in a header file.

	-hpa