ntohq/htonq?

[Warner Losh]

On Sep 14, 2011, at 11:46 AM, Julian Elischer wrote:

> 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.

I rather like this idea, but they definitely are non-standard.  htons grew up in an era that pre-dated intXX_t by a decade and there's been no updated, standardized versions since.  I'd make a subtle change to the XX versions: have them operate/return on the uintXX_t variants.  But I think that's also a separate discussion.

Warner