This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: =?gb2312?B?u9i4tDogT25lIHF1ZXN0aW9u?=
- To: N8TM at aol dot com
- Subject: Re: =?gb2312?B?u9i4tDogT25lIHF1ZXN0aW9u?=
- From: Per Bothner <bothner at cygnus dot com>
- Date: Wed, 12 Aug 1998 09:12:09 -0700
- cc: egcs at cygnus dot com
> As your example shows, PC compilers generally use the internal fully-reversed
> byte order, so, when reading a Unix data file, you will need reverse its
> bytes.
This description is wrong, or at least non-standard and misleading.
"internal fully-reversed" in comparison to what? What is a "Unix data file"
there are (and have "always" been) Unix machines with the same "reversed"
property as PCs.
Let's stick to the standard terminology for this: The Intel x86 architecture
is little-endian, which means that the low-order bit are considered "first".
(The low-ordered byte is the one with the smallest byte address.)
The same is true for the Vax, the Alpha, and other systems.
The Macintosh, Suns, and many other architectures are big-endian, which
means that the high-rder bit (and byte) are "first".
If you write a big-endian number to a file in memory byte order, and
then try read it back in on a little-endian machine, then you have
to reverse the bytes. But neither system or file format is inherently
"reversed" relative to some absolute standard, only different. (There
are arguments for either side of the big-endian and little-endian divide.)
--Per Bothner
Cygnus Solutions bothner@cygnus.com http://www.cygnus.com/~bothner