Re: Adding OpenBSD's endian functions betoh() / htobe() ?

[Nanno Langstraat <nlcom_os at ii dot nl>]

Nanno Langstraat wrote:
> It appears that there is no cross-Linux-BSD set of ready-made
> endian-conversion functions. From what I see, all application roll their
> own with a tangle of #ifdefs.
>
> [snip]
>   

Carlos O'Donell privately recommended that I present clearer pro/con for
creating cross-Linux-*BSD endianness macros, e.g. betoh64():


Pro:

    * The traditional 'htonl()' etc. don't have 64-bit variants.
    * The traditional 'htonl()' etc. don't have arbitrary-byte-alignment
      variants.

    * Need for *endian<-->host conversion is encountered by a large
      percentage of app programmers.
        (everything that needs to read a binary file or network packet)
        (these increasingly contain 64-bit fields)

    * It's nice for app programmers to have a standard set of macros on
      all/many common platforms. If we can create it for Linux + *BSD at
      least...

    * There are often opportunities for platform-specific optimizations
      (CPU bit-swizzling instructions), which is nice to maintain in a
      system library instead of in each application.

    * Nitpick: traditional 'htonl()' etc. equates 'short'/'long' with
      '16'/'32 bit', very obsolete and "wrong to teach".


Con:

    * Extra 1-3 KiB on every glibc installation.
    * Adds an extra include file.  (otherwise name clash with
      app-defined macros is likely).
    * Only fixes a minor annoyance for (many) app programmers.

----

Why in libc instead of kernel include files:

    * Application byte swizzling does not in any way involve the kernel.
    * Each of the Linux/*BSD/... kernels has its own set of endian
      macros, shaped by their own set of requirements.

----

Why in libc instead of some other library:

    * Too small for its own library
    * Very frequent need for these macros would make a separate library
      a requirement on any system anyway.

----

    Cheers,
    Nanno