Linus> On Fri, 5 Dec 1997, Jes Sorensen wrote:
>> The hton[sl]() stuff is horribly broken!
Linus> You aren't really batting a thousand today..
>> hton[sl]() _must_ be implemented using inline functions, using
>> defines breaks the networking part of libc.
Linus> No. hton[sl] _must_ be implemented as defines, because doing
Linus> them as inline functions breaks the nice optimization that you
Linus> were so proud of just two emails ago. Gcc doesn't do constant
Linus> propagation into inline functions (I do hope egcs will fix
Linus> this), so the __builtin_constant_p() thing doesn't work unless
Linus> it's a define.
This will work on little endian boxes, but it breaks on big endian.
Example, with the new patch we get from
linux/include/linux/byteorder_big_endian.h:
#define __cpu_to_be32(x) ((__u32)(x))
In linux/include/linux/byteorder_generic.h this is used for htonl():
#define ___htonl(x) __cpu_to_be32(x)
#define ___htons(x) __cpu_to_be16(x)
#define ___ntohl(x) __be32_to_cpu(x)
#define ___ntohs(x) __be16_to_cpu(x)
#define htonl(x) ((unsigned long)___htonl(x))
Which will simply turn into `x'. This will break libc if you build it
against these headers! At least that was what happend back when I made
the mistake of defining htonl(x) directly to x back in late 1.3.x (or
was it early 2.1.x - can't remember, Andreas corrected this at some
later point).
What I don't like against this current approach is that the header
files in include/linux are mastering the access to the swap
functions. I would much rather like to see this done by having a
library as I mentioned and then a list of defines in
asm-foo/byteorder.h that uses these macros. These library macros can
use the constant tricks etc. to optimize when appropriate.
For people using the standard versions of the functions,
asm-foo/byteorder.h will simply turn into 6 defines for the cpu_to_x()
macros in this file. This will result in the same optimisation but
will IMHO be much easier to read.
Ok this seems to have turned into a religious issue now, but the
hton[sl]() is still valid as far as I can see.
Jes