This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: BZ#13926: Add __bswap_64 for non-GCC compilers
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