From owner-freebsd-arch@FreeBSD.ORG Wed Sep 14 16:31:32 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 28516106566C for ; Wed, 14 Sep 2011 16:31:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F33608FC1B for ; Wed, 14 Sep 2011 16:31:31 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A8E2246B09; Wed, 14 Sep 2011 12:31:31 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4DC148A02E; Wed, 14 Sep 2011 12:31:31 -0400 (EDT) From: John Baldwin To: Warner Losh Date: Wed, 14 Sep 2011 12:30:51 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> <201109140747.21979.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109141230.51827.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 14 Sep 2011 12:31:31 -0400 (EDT) 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 16:31:32 -0000 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). -- John Baldwin