From owner-freebsd-arch@FreeBSD.ORG Wed Sep 14 17:12:34 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B8E1106564A; Wed, 14 Sep 2011 17:12:34 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2C5478FC08; Wed, 14 Sep 2011 17:12:34 +0000 (UTC) Received: from [10.0.0.163] ([12.186.246.114]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p8EH4Lw8056212 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 14 Sep 2011 11:04:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4E70DA7A.7020307@freebsd.org> Date: Wed, 14 Sep 2011 12:04:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <94A8CF2C-432D-43D6-8FB6-ADDAA013CA9D@bsdimp.com> References: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> <201109140747.21979.jhb@freebsd.org> <201109141230.51827.jhb@freebsd.org> <4E70DA7A.7020307@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 14 Sep 2011 11:04:25 -0600 (MDT) Cc: freebsd-arch@freebsd.org, Marcel Moolenaar Subject: Re: ntohq/htonq? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 17:12:34 -0000 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: >>>=20 >>>> On Tuesday, September 13, 2011 10:36:49 pm Marcel Moolenaar wrote: >>>>> All, >>>>>=20 >>>>> Is there a reason not to add ntohq and htonq to the short >>>>> and long versions we (and everyone else) already has? >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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). >>>>=20 >>>> 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?))). >>>>=20 >>> Looks like the hotel ate my reply... >>>=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 > 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. >=20 > 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=