Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Michael Caisse (boost_at_[hidden])
Date: 2010-05-29 12:28:27
Terry Golubiewski wrote:
>> The term "network byte order" means the same to everyone who has had
>> to learn what endianness is. Why would one want ignore that the term
>> "network byte order" has real meaning in an endianness library? That
>> there are legitimate use cases for sending little-endian data over
>> the network is, to me, irrelevant.
>>> Are you saying that you would like it to do so? Or are you saying
>>> you would
>>> like to have another typedef, "machine_to_network"?
>> Acknowledging "network byte order" in the interface does not
>> prescribe anything. I am suggesting is that it should be a
>> consistent synonym for "big endian". Virtually all IETF binary
>> protocols specify /network byte order/ and everyone who reads the
>> RFCs knows what that means. One need only google 'rfc "network byte
>> order"' to get a feel for its pervasiveness. Ignoring it completely
>> seems silly.
>>> I *could* add that with no problems, of course, BUT like I said,
>>> that typedef
>>> may mean different things to different people. I would almost
>>> prefer for this
>>> to be an application specific define
>> But it's not application-specific. It's a de facto world-wide standard.
> There are other networks besides the internet, some that don't use IP
> and are not big-endian by default.
> It would probably make sense to have an "internet" namespace that has
> all that stuff predefined somewhere.
> Endianess is a bigger concept than the internet, especially for
> embedded software that uses several dissimilar processors, but might
> not have any "network" interface.
> BTW there are other endiannesses besides "bit" and "little" too, but I
> haven't seen any processors with "middle-endian" like that since the
> PDP (if that was the one).
> Endianess is not just byte-swapping either. A big-endian, floating
> point representation and a little-endian representation of the same
> kind of floating point number may not be simple byte-reflections of
> each other.
Tom / Terry -
I don't think the point being made is that there are not different
endian formats on networks but that the term "network byte order"
actually means something. It is not a wishful or ambiguous description
it is actually a real term with real meaning. Thanks to the Berkeley API
that many of us grew up with "host to network" also has real meaning.
I'm not suggesting that the term "network" should even appear in an
endian library. I would prefer the term to only exist in some domain
specific namespace; however, ignoring well over 20-years of terminology
history isn't going to make things clearer in the interface.
Can we keep the term network out of the main interface and simply add it
to namespaces as Terry has suggested?
Tom, I'm looking forward to reading more about your library.
Best regards -
-- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com