Linus> On 5 Dec 1997, Jes Sorensen wrote:
>> Which will simply turn into `x'. This will break libc if you build
>> it against these headers!
Linus> Why? ((unsigned long)(__u32)(x)) is the _correct_ answer on a
Linus> big-endian machine. How could that break libc?
Linus> If libc internally tries to do the htonl() functions and the
Linus> above breaks the function declaration, then libc is _wrong_.
I have been through my archives, without luck, hoping to find the
patch with the explanation from Andreas. However, what I did find was
an old posting from a guy having problems with libc-5.3.12 missing the
ntoh and hton functions.
Linus> As mentioned earlier, htonl() has traditionally always been
Linus> just the identity macro on big-endian systems, so if libc can't
Linus> handle it then libc is broken pretty much by definition. But
Linus> this should be easy to fix: when libc wants to actually
Linus> implement the functions internally, just add a
We changed them to inline functions because libc-5.3.12 broke when
compiled against such headers. I do not know whether this has been
fixed during the 5.4.x development or in glibc - maybe someone else
can clarify here.
Jes