Date: Wed, 23 Jun 2010 09:50:26 -0700 From: Randall Stewart <rrs@lakerest.net> To: Bruce Evans <brde@optusnet.com.au> Cc: Luigi Rizzo <rizzo@iet.unipi.it>, net@FreeBSD.org Subject: Re: Observations from an old timer playing with 64 bit numbers... Message-ID: <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> In-Reply-To: <20100623232402.X45536@delplex.bde.org> References: <E3C4102C-3106-4D5B-86E5-8D5BDD7FD442@lakerest.net> <20100622221228.GA93249@onelab2.iet.unipi.it> <20100623232402.X45536@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce:
Comments (and questions in-line)... (you too Luigi)
On Jun 23, 2010, at 6:33 AM, Bruce Evans wrote:
> On Wed, 23 Jun 2010, Luigi Rizzo wrote:
>
>> On Tue, Jun 22, 2010 at 05:46:02PM -0400, Randall Stewart wrote:
>>> Hi all:
>>>
>>> I have had some fun in my day job playing with exchanging 64bit
>>> numbers. Unfortunately
>>> there is no ntohll() OR htonll() which would be the logical thing
>>> (for
>>> us old farts) to use.
>>>
>>> Yes, I have found htobe64() and friends.. and that would work..
>>> but I
>>> still cannot
>>> help but feeling we should have the ntohll() and htonll().. for
>>> consistency if nothing
>>> else.
>>>
>>> Any objections to this showing up in a head near you soon (speak
>>> soon
>>> or I will commit
>>> the patches to add these ;-D)
>>
>> 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
received a few private comments to the effect that "Gee, we would like
that, we rolled our own versions of ntohll() and if you did it we could
remove our version". This tells me that although a nicer name, folks
are rolling their own due to the name. Having a #define that maps
ntohll -> be64toh will make it so that people can actually find
the function. Name changes are a good thing for clarity but if no
one will use your changed name and roll their own.. thats a bad thing.
By having such a define you might encourage folks (over time) to
transition
off to the more clear naming versions..
>
> Yes, long long should not exist, and there are few places where exact
> sizes should be used, but networking code is one place where they
> should be used.
>
> ntohs() will break semantically or actually on machines with shorts
> with
> more than 16 bits.
So two questions here:
a) What machines that we do support currently have a short larger than
16bits?
b) Does anyone that use networking code really expect ntohs() to do
anything
different than a 16 bit byte swap? The man page is pretty clear on
it i.e. uint16_t is the input and its a "network short" which
if I remember right is defined to be 16 bits... At least most RFC's
are pretty clear and the same is true for UNP Vol 1 ;-)
>
> ntohl() is already broken semantically on machines with longs with
> more than 32 bits (all 64-bit arches in FreeBSD). It doesn't actually
> handle longs on such arches. Networking code handles a few cases
> related
> to this with n_long. This is not quite as bad, but its name is
> nonsense --
> n_long is very far from being a long -- it is unsigned 32 bits
> exactly,
> unlike long which is signed >= 32 bits.
again same two questions only change them to say 32 bits?
>
> ntohll() would break similarly on machines with long longs with more
> or less than 64 bits. In practice this and other misuses of long long
> may prevent the size of long long being changed, like it prevented the
> size of long being changed on some systems with historical abuses of
> long.
Again same first question... the second one I would ask too except the
function
does NOT exist (except where folks go out and roll it themselves).
Basically I don't agree with your assessment since these functions are
designed
to operate on network code which I think defines a short = 16, a long
= 32 (at least
all RFC's I have read do that anyway). And it appears from feedback I
have received
that ntohll would be defined as a 64bit network quantity in most folks
minds since
that what a lot of folks have implemented...
R
>
> Bruce
>
------------------------------
Randall Stewart
803-317-4952 (cell)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9C936FEB-4858-4D8D-89CC-182EA3A80365>