Re: Big Endian - Little Endian
On Aug 27, 4:04 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On 27 Aug, 14:39, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
Juha Nieminen <nos...@thanks.invalid> writes:
dertop...@web.de wrote:
<snip>
Moreover, does the standard guarantee that you can
reinterpret-cast an int* to a char*, and then dereference
it safely?
AFAIK, no. That is, there could be pad bits, or some other
strange mapping, so the test proposed wouldn't be right.
But in practice, on current machines, it works.
C (and by inheritance C++) guarentees that you can cast any
data pointer ("object" in C-speak) to a pointer to unsigned
char and be able to deref it. Hence you can always hex
dump the representation of an object. U chars *cannot*
have trap representations.
The C++ standard also makes this guarantee for char, I think.
On the other hand, it doesn't guarantee that two char's which
compare equal will have the same bit representation; only
unsigned char guarantees that.
Also Big-endian and Little-endian doesn't exhaust the
possibilities, there are strange DEC-endians as well.
Or earlier versions of Microsoft C on a PC, where 32 bit longs
had the order 2301 (where each digit is the power of 256
represented in the byte). Note too that there are (currently)
machines with 9 bit char's, machines where int's contain padding
bits, machines which don't use 2's complement, etc.
Pascal stated it more or less clearly. Internally, you don't
care about byte order---there may not even be any. Externally,
the protocol defined the *values* for each octet, given a
integral value; you use value operations on the int to get them.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34