[7jjjjjjj]

It goes without saying that all binary network protocols should document their byte order, and that if you're implementing a protocol documented as big endian you should use ntohl and friends to ensure correctness.

However if designing a new network protocol, choosing big endian is insanity. Use little endian, skip the macros, and just add

  #ifndef LITTLE_ENDIAN
    #error

Or the like to a header somewhere.

[AnthonyMouse]

What does it actually cost you to define a macro which is a no-op on little endian architectures and then use it at the point of serialization/deserialization?

[kccqzy]

A lot because to the compiler a no-op macro is the same as not having the macro in the same place so it won’t catch cases where you should use the macro but didn’t. Then you just give yourself a false sense of security unless you actually test on big endian.

[AnthonyMouse]

The article demonstrates how you can run your existing test suite on big endian with a few simple commands. Or you can just wait until someone actually wants to use it there, they run your program or test suite on their actual big endian machine and then you get a one-line pull request for the place you forgot to use the macro.

Adding other architectures to your build system also tends to reveal nasty bugs in general, e.g. you were unknowingly triggering UB on all architectures but on the one you commonly use it causes silent data corruption whereas one with a different memory layout results in a much more conspicuous segfault.