Hacker News Reader

Comment by rwmj | Hacker News Reader

If you can assume GCC or Clang then __builtin_bswap{16,32,64} functions are provided which will be considerably more efficient, less error-prone, and easier to use than anything you can homebrew.

View on HN

Well, yes. The only thing missing is knowing if you have to swap or not, if you don't want to assume your code will run on little endian systems exclusively.

Or, on Linux and BSD systems at least, you can use the <endian.h> or <sys/endian.h> functions (https://linux.die.net/man/3/endian) and rely on the libc implementation to do the system/compiler detection for you and use an appropriate compiler builtin inside of an inline function instead of bothering to hack something together in your own code.

The article mentions those functions at the bottom, but strangely still recommends hacking up your own macros.

My favourite builtins are the overflow checked integer operations:

https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...

But then you have to #ifdef the endianness of the target architecture. If you do it the right way as Russ Cox and Justine Tunney say, then your code can serialize and deserialize correctly regardless of the platform endianness.

That's not true. If you write the byte swap in ANSI C using the gigantic mask+shift expression it'll optimize down to the bswap instruction under both GCC and Clang, as the blog post points out.

Assuming the macros or your giant expression are correct. But you might as well use the compiler intrinsics which you know are both correct and the most efficient possible, and get on with your life.

Sorry I'd rather place my faith in arithmetic rather than someone's API provided the compiler is smart enough to understand the arithmetic and optimize accordingly.

"Someone" here is the same compiler you're trusting to optimize your giant arithmetic expression of the same idea. Your statement is internally inconsistent.

There is a value to keeping it completely clear in your head the difference between a value with arithmetic semantics vs a value with octets in a stream semantics. That thinking will work in all contexts, while the compiler knowledge is limited. The thinking will help you write correct ways to encode data in the URL or into a file being uploaded that your code generates for discord or whatever, in Python, without knowledge of the true endianness of the system the code is running on.

Funny that compilers (e.g. clang: https://github.com/llvm/llvm-project/blob/b04148f77713c92ee5... ) might be able to do that only because someone on the compiler team has hand-coded a bswap expression detector.

The fallacy in the article is that anyone should code these functions. There's plenty of public domain libraries that do this correctly.

https://github.com/rustyrussell/ccan/blob/master/ccan/endian...

_byteswap_{ushort,ulong,uint64} for MSVC. Together with yours on x86 these should take care of the three major compilers.

The article explicitly shows that the provided macros are very efficient with a modern compiler. You can check on godbolt.org that they emit the same code.

Though the article only mentions bswap64 and mentioning __builtin_bswap64 would be a nice addition.

Given it can be done with careful code AND many processors have a single instruction to do it I’m surprised it hasn’t been added to the C standard.

__builtin_bswap does exactly the same thing as the macros.

Reply on news.ycombinator.com