On 03/28/2012 07:05 PM, Jakub Jelinek wrote:
> On Wed, Mar 28, 2012 at 04:51:00PM +0200, Andreas Jaeger wrote:
>> +#else
>> +# define __bswap_constant_64(x) \
>> + ((((x)& 0xff00000000000000ul)>> 56) \
>> + | (((x)& 0x00ff000000000000ul)>> 40) \
>> + | (((x)& 0x0000ff0000000000ul)>> 24) \
>> + | (((x)& 0x000000ff00000000ul)>> 8) \
>> + | (((x)& 0x00000000ff000000ul)<< 8) \
>> + | (((x)& 0x0000000000ff0000ul)<< 24) \
>> + | (((x)& 0x000000000000ff00ul)<< 40) \
>> + | (((x)& 0x00000000000000fful)<< 56))
>> +
>> +static __inline unsigned long long int
>> +__bswap_64 (unsigned long long int __bsx)
>> +{
>> + return __bswap_constant_64 (__bsx);
>> +}
>
> How do you know that the non-GCC compiler in question supports
> unsigned long long type at all? It is not a standard C89 type...
> Why are you using ul rather than ull suffixed constants?
This is copied from the s390 implementation - which I'll fix if we can
agree on how to do it.
right now the installed header strings/endian.h contains:
# define htobe64(x) __bswap_64 (x)
# define htole64(x) (x)
# define be64toh(x) __bswap_64 (x)
# define le64toh(x) (x)
So, IMO we should have a definition for __bswap_64.
Would the patch be ok if do the changes that Roland suggested and use
ull instead (and fix the s390 version the same)?
I do think we require already that a compiler supports "long long" -
looking at the installed headers there are many places in installed
headers that use long long already. But I found __GLIBC_HAVE_LONG_LONG
in <features.h>. Should I just guard the definition by this? What shall
we do if it's false - just fail silently?
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126