ntohq/htonq?
John Baldwin
jhb at freebsd.org
Wed Sep 14 11:48:43 UTC 2011
On Tuesday, September 13, 2011 10:36:49 pm Marcel Moolenaar wrote:
> All,
>
> Is there a reason not to add ntohq and htonq to the short
> and long versions we (and everyone else) already has?
>
> Juniper has 64-bit entities that go over the wire in
> network byte order and, while these macros are absolutely
> arcane, I see no reason not to complete them with 64-bit
> variants.
>
> I did some googling and htonq and ntohq seem to be de
> facto names used, but oddly enough no OS has them defined.
> It's surreal. Are there better alternatives we should
> migrate to?
I don't have a better idea. I do wish the names encoded the size instead like
we do for the [lb]etoh*() and hto[lb]e*() macros (that is ntoh64(), etc.).
However, given that ntohl() and ntohs() are standardized we've probably lost
the opportunity to fix that misfeature of ntoh*() and hton*() and a 'q' suffix
is consistent (though hackish).
I guess the one other possiblity is to add *16 and *32 aliases for 's' and 'l'
and then add *64 for the new one if we think that using the names is better
for the future (e.g. ntoh128() when it comes (or will that be ntoho()
(octword?))).
--
John Baldwin
More information about the freebsd-arch
mailing list