ntohll/htonll? [was: Re: ntohq/htonq?]
imp at bsdimp.com
Wed Sep 14 18:19:14 UTC 2011
On Sep 14, 2011, at 12:14 PM, Marcel Moolenaar wrote:
> [changing subject to tie *ll to *q for search purposes]
> On Sep 14, 2011, at 9:30 AM, John Baldwin wrote:
>> On Wednesday, September 14, 2011 10:39:31 am Warner Losh wrote:
>>> 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).
> 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...
> 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...
More information about the freebsd-arch