From owner-freebsd-arch@FreeBSD.ORG Wed Sep 14 11:48:43 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 7726C106566B for ; Wed, 14 Sep 2011 11:48:43 +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 509688FC18 for ; Wed, 14 Sep 2011 11:48:43 +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 0691A46B0A; Wed, 14 Sep 2011 07:48:43 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7F07B8A037; Wed, 14 Sep 2011 07:48:42 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 14 Sep 2011 07:47:21 -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> In-Reply-To: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109140747.21979.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 14 Sep 2011 07:48:42 -0400 (EDT) Cc: 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 11:48:43 -0000 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?))). -- John Baldwin