Date: Wed, 14 Sep 2011 07:47:21 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: ntohq/htonq? Message-ID: <201109140747.21979.jhb@freebsd.org> In-Reply-To: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> References: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201109140747.21979.jhb>