Date: Wed, 14 Sep 2011 13:12:58 -0500 From: Warner Losh <imp@bsdimp.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: freebsd-arch@freebsd.org Subject: Re: ntohll/htonll? [was: Re: ntohq/htonq?] Message-ID: <E14E1D75-F7D0-4089-9D93-B0B8E43E2251@bsdimp.com> In-Reply-To: <A50A53FC-3141-4393-8B32-9248A9BD13A5@xcllnt.net> 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> <A50A53FC-3141-4393-8B32-9248A9BD13A5@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 14, 2011, at 12:14 PM, Marcel Moolenaar wrote: > [changing subject to tie *ll to *q for search purposes] >=20 > On Sep 14, 2011, at 9:30 AM, John Baldwin wrote: >=20 >> On Wednesday, September 14, 2011 10:39:31 am Warner Losh wrote: >>>=20 >>> hton64/ntoh64 is what Linux has in the kernel. htonll and ntohll is = what Solaris and AIX have. >>>=20 >>> 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. >>=20 >> Actually, come to think of it, we use *ll rather than *q variants = here at work >> as well. I'd vote for (2). >=20 > The only problem I'm facing is that htonq/ntohq are well-established > and heavily used within Junos. They are even exposed in the SDK. So, > while I don't mind taking a slightly different route, I do need to > deal with compatibility. But if I need to do that, then there's also > no real reason anymore to add a 64-bit variant to FreeBSD. I need to > see what is possible... >=20 > Anyway: I sense a preference for a numerical suffix over any single > or multi-letter suffix. There's no reason not to support all 3. They'd all be in the BSD name = space anyway... My hesitance to do that is based on my intuition, but = there's no actual resistance so far in this thread... Sometimes doing = the little things like this can help a huge amount. The one down side would be for those applications that have defined = these routines themselves might need minor tweaking for FreeBSD. I = suspect that this question could be answered by a simple ports run. I = think that body of software would be a good estimator for all = third-party software... Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E14E1D75-F7D0-4089-9D93-B0B8E43E2251>