From owner-freebsd-arch@FreeBSD.ORG Wed Sep 14 14:48:45 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 D9D99106566B; Wed, 14 Sep 2011 14:48:45 +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 980F38FC0C; Wed, 14 Sep 2011 14:48:45 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p8EEdZcr054475; Wed, 14 Sep 2011 08:39:36 -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: <201109140747.21979.jhb@freebsd.org> Date: Wed, 14 Sep 2011 09:39:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> <201109140747.21979.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [127.0.0.1]); Wed, 14 Sep 2011 08:39:37 -0600 (MDT) Cc: Marcel Moolenaar , freebsd-arch@FreeBSD.org 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 14:48:45 -0000 On Sep 14, 2011, at 6:47 AM, John Baldwin wrote: > 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? >=20 > I don't have a better idea. I do wish the names encoded the size = instead like=20 > we do for the [lb]etoh*() and hto[lb]e*() macros (that is ntoh64(), = etc.). =20 > However, given that ntohl() and ntohs() are standardized we've = probably lost=20 > the opportunity to fix that misfeature of ntoh*() and hton*() and a = 'q' suffix=20 > is consistent (though hackish). >=20 > I guess the one other possiblity is to add *16 and *32 aliases for 's' = and 'l'=20 > and then add *64 for the new one if we think that using the names is = better=20 > for the future (e.g. ntoh128() when it comes (or will that be ntoho()=20= > (octword?))). >=20 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. Warner