From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 19:57:17 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA8AA106564A for ; Wed, 23 Jun 2010 19:57:17 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 798138FC0C for ; Wed, 23 Jun 2010 19:57:17 +0000 (UTC) Received: from mobile-166-187-091-069.mycingular.net (mobile-166-187-091-069.mycingular.net [166.187.91.69] (may be forged)) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o5NJv4c9012600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Jun 2010 15:57:11 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1277323033; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=HVBmkIt1rOH2aHsNIX0utzPI7TKRrNbwGEm/nJ/g4ReDylJKU9DE265 9SStyECot4YHfQMXuXb0bOnPSUq1Hwg== Message-Id: From: Randall Stewart To: Julian Elischer In-Reply-To: <4C226354.80601@elischer.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 23 Jun 2010 12:56:58 -0700 References: <20100622221228.GA93249@onelab2.iet.unipi.it> <20100623232402.X45536@delplex.bde.org> <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> <20100623171222.GA7981@onelab2.iet.unipi.it> <4C226354.80601@elischer.org> X-Mailer: Apple Mail (2.936) Cc: Luigi Rizzo , net@freebsd.org Subject: Re: Observations from an old timer playing with 64 bit numbers... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 19:57:18 -0000 On Jun 23, 2010, at 12:41 PM, Julian Elischer wrote: > On 6/23/10 10:12 AM, Luigi Rizzo wrote: >> On Wed, Jun 23, 2010 at 09:50:26AM -0700, Randall Stewart wrote: >> ... >>>>> strong objection! >>>>> We should instead use names with exact sizes (16,32,64). >>> >>> So please tell me why you object so strongly? We have the 16/32/64 >>> bit >>> names which >>> are nice but are not expected so folks seem to not use them. I have >> >> people's ignorance is not an excuse for not doing things right. >> We'd still be using BYTE, WORD and DWORD otherwise. >> >> I think there is no doubt that we should use the 16/32/64 bit names >> if we could start from scratch, and the only reason for not doing >> so is avoiding gratuitous changes to existing/stable code. >> >> The case of *to*ll does not apply, in that there is no actual legacy >> to adapt to. And btw there is tons of places which use the 16/32/64 >> bit >> names in the filesystem, usb and generic device drivers. In fact, >> many more than ntohl/htonl >> >> > grep -r be32 ~/FreeBSD/head/sys/ | grep -v .svn | wc >> 1438 6397 145174 >> > grep -r le32 ~/FreeBSD/head/sys/ | grep -v .svn | wc >> 2203 10269 210989 >> > grep -r ntohl ~/FreeBSD/head/sys/ | grep -v .svn | wc >> 854 4009 84855 >> > grep -r htonl ~/FreeBSD/head/sys/ | grep -v .svn | wc >> 738 3604 72970 > > > what he said.. > > if you want to have ntohll in SCTP then that is your choice, SCTP does not have a case for sending 64 bit things... This is my day job and other folks looking for nothll() and friends... > but I think it > should be a local define to be64toh or ntoh64 > I do prefer the ntoh64 version but beXXtoh or whatever it looks like > others are using is ok to me too since 'net' is a pretty wide > definition and not ALL protocols are big endian. Well thats fine, we can let folks continue rolling there own if thats what y'all want. I really don't care actually... I already have the ifdef's in place in my day-job app code.. so its no big deal ;-) I will make this last comment.. directed at Luigi in response to: >> people's ignorance is not an excuse for not doing things right Then I would strongly suggest you go fix the manual page for ntohl/ ntohs and point people to the be64toh() functions... then people would NOT be ignorant. The problem is there is NO clue in the system... R ------------------------------ Randall Stewart 803-317-4952 (cell)