Adding OpenBSD's endian functions betoh() / htobe() ?
Nanno Langstraat
nlcom_os@ii.nl
Sun May 4 15:09:00 GMT 2008
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
More information about the Libc-alpha
mailing list