Re: BZ#13926: Add __bswap_64 for non-GCC compilers

[Roland McGrath <roland at hack dot frob dot com>]

> This is copied from the s390 implementation - which I'll fix if we can 
> agree on how to do it.

Yeah, it might only have been tested on s390x where UL is 64 bits.

> 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.

Well, all the support for non-GCC compilers (or at least compilers not
pretending to be GCC) is fairly spotty.

> Would the patch be ok if do the changes that Roland suggested and use 
> ull instead (and fix the s390 version the same)?

I think it would be OK.  But as to whether it's a potential regression,
that would have to be tested by some particular non-GCC compilers one
has in mind.  Personally, I don't have any such compilers in mind.

> 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?

__GLIBC_HAVE_LONG_LONG is used a few similar places, so using it in
endian.h seems consistent.  In the existing uses in stdlib.h, the
interfaces are just not declared.  But those are ones where the types in
the signature are explicitly 'long long' types.  In endian.h, the putative
type should actually be uint64_t.  So if there is a compiler+target where
'long long' is not supported but 'long' is 64 bits, that would fail there.

However, the closest existing model is <byteswap.h> (string/byteswap.h),
which conditionalizes the bswap_64 declaration for GCC>=2, which presumably
intends to be the __GLIBC_HAVE_LONG_LONG sort of check.  So that says just
omit everything 64-bit #ifndef __GLIBC_HAVE_LONG_LONG.

Last I checked, neither <byteswap.h> nor <endian.h> were standardized
anywhere.  So another tack would be to make them include <stdint.h> and
then use uint64_t and UINT64_C.  But that complicates life for C++, where
<stdint.h> might not define UINT64_C.


Thanks,
Roland