From owner-freebsd-net@FreeBSD.ORG Fri Jun 25 17:51:00 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 3FF24106566B for ; Fri, 25 Jun 2010 17:51:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id C8EE98FC19 for ; Fri, 25 Jun 2010 17:50:57 +0000 (UTC) Received: from c122-107-125-7.carlnfd1.nsw.optusnet.com.au (c122-107-125-7.carlnfd1.nsw.optusnet.com.au [122.107.125.7]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o5PHop6D019953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jun 2010 03:50:52 +1000 Date: Sat, 26 Jun 2010 03:50:51 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Randall Stewart In-Reply-To: Message-ID: <20100626032941.U47182@delplex.bde.org> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Luigi Rizzo , Julian Elischer , 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: Fri, 25 Jun 2010 17:51:00 -0000 On Wed, 23 Jun 2010, Randall Stewart wrote: > On Jun 23, 2010, at 12:41 PM, Julian Elischer wrote: >> 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. A global define for ntoh64 would be reasonable. It wouldn't be OK if 'net' were so wide, but I think it basically requires big endian (there must be an endianness and there shouldn't be 2). > 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... The man page is indeed not good. It is too general, and I noticed the following errors in its details: % BYTEORDER(3) FreeBSD Library Functions Manual BYTEORDER(3) It is far from being about general byte order macros (those are mainly the be/le ones in byteorder(9)... % % NAME % htonl, htons, ntohl, ntohs -- convert values between host and network % byte order ... it is only about these network functions. % DESCRIPTION % These routines convert 16 and 32 bit quantities between network byte % order and host byte order. On machines which have a byte order which is % the same as the network order, routines are defined as null macros. s/routines/these routines/ s/null/null filter/ [but needs more work:] Saying that the routines are defined as null macros gives too much detail, and the detail is wrong. The "routines" are actually defined as deeply nested macros in all cases (but are backed up by real routines, i.e., extern functions) for when the macros are #undefed). Then, on machines which have a byte order which is the same as the network order, the macros end up expanding to the non-quite null filter of (type)(arg), where `type' is the relevant type. But this is too much detail. % SEE ALSO % gethostbyname(3), getservent(3), byteorder(9) I find cross references like this worse than useless. The relevant functions should be mentioned in the description, with specific cross references there, and there should be no generic cross references in the SEE ALSO section. Bruce