Date: Wed, 14 Sep 2011 09:46:50 -0700 From: Julian Elischer <julian@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-arch@freebsd.org, Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: ntohq/htonq? Message-ID: <4E70DA7A.7020307@freebsd.org> In-Reply-To: <201109141230.51827.jhb@freebsd.org> References: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> <201109140747.21979.jhb@freebsd.org> <B76A2235-C31A-46B6-BB99-EC9A661D83BD@bsdimp.com> <201109141230.51827.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/14/11 9:30 AM, John Baldwin wrote: > 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). > it won't cost us to provide ntoh16, ntoh32, ntoh64 even if we do also have ntohs, ntohl, ntohll AND ntohq. just make it clear in the definitions which one we want people to use in new code. ntohs, and ntohl have alway annoyed me just like 'short' and 'long' and 'long long' these days I always try use "int32_t" stuff if it's going to be exported anywhere.. and I think the same should be true of the ntohXX stuff.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E70DA7A.7020307>