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