Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Terry Golubiewski (tjgolubi_at_[hidden])
Date: 2010-05-29 00:02:17
> 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
>> 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
>> may mean different things to different people. I would almost prefer for
>> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk