On Sat, Sep 03, 2005 at 10:43:15AM +0200, Harald Welte wrote:
> htonll() is nothing else than cpu_to_be64(), so we'd rather call the
> latter.
Actually, the htonll() implementation does not seem to be doing what
cpu_to_be64() is doing.. However, I would assume this is a bug in
htonll() and this change to use cpu_to_be64() is fixing that. Can this
bug cause any major problems in the current implementation?
> -u_int64_t htonll(u_int64_t in)
> -{
> - u_int64_t out;
> - int i;
> -
> - for (i = 0; i < sizeof(u_int64_t); i++)
> - ((u_int8_t *)&out)[sizeof(u_int64_t)-1] = ((u_int8_t *)&in)[i];
I would assume that the first index should have had '-i' added to it, if
the purpose is to swap byte order.. The code here is leaving some
arbitrary data in 7 bytes of the 64-bit variable and setting
(u8*)&out[7] = (u8*)&in[7] in somewhat inefficient way ;-). In addition,
this looks more like swap-8-bytes-unconditionally than doing this based
on host byte order..
--
Jouni Malinen PGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
