ntohq/htonq?

John Baldwin jhb at freebsd.org
Wed Sep 14 16:31:32 UTC 2011


On Wednesday, September 14, 2011 10:39:31 am Warner Losh wrote:
> 
> On Sep 14, 2011, at 6:47 AM, John Baldwin wrote:
> 
> > 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?))).
> > 
> 
> Looks like the hotel ate my reply...
> 
> hton64/ntoh64 is what Linux has in the kernel.  htonll and ntohll is what Solaris and AIX have.
> 
> So (1)  I'd shy away from htonq since that's not as well established as the other two in the OS (although googling suggests that many programs use 
it). (2) I'd provide both htonll and hton64 with a note saying that hton128 is the wave of the future.

Actually, come to think of it, we use *ll rather than *q variants here at work
as well.  I'd vote for (2).

-- 
John Baldwin


More information about the freebsd-arch mailing list