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)
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
