Does endian-ness matter?

SDL Development
1

I apologise in advance for the off-topic post, but I’m hoping that I’ll be
forgiven since it arises from my work with the SDL. If someone could point
me at a more appropriate forum, I’ll gladly relocate the question…

I understand the byte-ordering difference that defines Little- and Big-
Endian schemes. I’ve assumed from what I’ve seen in the SDL documentation
that when writing portable code one must cater for both platform-types.
Recent discussions that I’ve had with people in the office suggest that this
is not the case, and that the standard for C as a language is a Big-
Endian representation, i.e, that to get the least signifcant byte of a 32-bit
int, the mask 0x0000000f can be used REGARDLESS of whether the underlying
hardware is Little- or Big-Endian. The Assumption being that the compiler
will assumes that code is written in this way and will perform the necessary
byte-swapping dependant on the platform.

If this is correct, then why the need for different RGBA masks in the SDL for
BIG and LIL endian platforms? If anyone could point me at a reference, or
is willing to explain how this really works to me, I would greatly appreciate
the enlightenment. This is quite a big hole in my education that I’d like to
fill.

With thanks
.marc

2

Marc Daya wrote:

Recent discussions that I’ve had with people in the office suggest that this
is not the case, and that the standard for C as a language is a Big-
Endian representation, i.e, that to get the least signifcant byte of a 32-bit
int, the mask 0x0000000f can be used REGARDLESS of whether the underlying
hardware is Little- or Big-Endian. The Assumption being that the compiler
will assumes that code is written in this way and will perform the necessary
byte-swapping dependant on the platform.

Kind of… that number will always be equal to 15, and be stored with the
navive endianness of the platform the program is compiled for.

If this is correct, then why the need for different RGBA masks in the SDL for
BIG and LIL endian platforms? If anyone could point me at a reference, or
is willing to explain how this really works to me, I would greatly appreciate
the enlightenment. This is quite a big hole in my education that I’d like to
fill.

It is because of the very fact you mentioned above - the compiler will convert
the number in the source code to the native byte order - that swapping is
necessary for RGBA values being passed to OpenGL. OpenGL, as far as I can tell,
treats the pixel as an array of bytes, not a number. It takes the first byte as
red, the second as green, the third as blue, and the fourth as alpha. Thus, the
masks have to be in the same order regardless of system byte order.

For example, the red must be in the first byte, so the mask must be stored as
follows (this is the actual sequence of bytes):

FF 00 00 00

On big-endian machines, 0xff000000 gives this, because the high-order byte
comes first. But on little-endian machines, the low-order byte comes first, so
0x000000ff gives the desired byte sequence.

Basically, the problem arises because the compiler does not know when you want
a raw sequence of bytes and when you want a number that can be processed by
the CPU. Because numbers are much more commonly desired than raw bytes, the
standard behaviour is to treat it as a number, and convert to the processor’s
byte order. Thus, you need to introduce your own swap back if you need the
bytes in a specific order (as does OpenGL).

Chris E.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050721/4ff2cdfc/attachment.pgp

3

atform.

If this is correct, then why the need for different RGBA masks in the SDL for
BIG and LIL endian platforms? If anyone could point me at a reference, or
is willing to explain how this really works to me, I would greatly appreciate
the enlightenment. This is quite a big hole in my education that I’d like to
fill.

endian-ness DOES matter. The compiler is not really a concern as it
converts any numbers you type in to the correct endian.

The main area where you will have problems is with binary files. For
example if you use “fwrite” to write a ‘float’ to a file on a little
endian machine. Then you use “fread” on the big-endian machine to read
the file back in, the bytes will be read in in the wrong order.

  • Tom
4

I understand the byte-ordering difference that defines Little- and Big-
Endian schemes. I’ve assumed from what I’ve seen in the SDL documentation
that when writing portable code one must cater for both platform-types.
Recent discussions that I’ve had with people in the office suggest that this
is not the case, and that the standard for C as a language is a Big-
Endian representation, i.e, that to get the least signifcant byte of a 32-bit
int, the mask 0x0000000f can be used REGARDLESS of whether the underlying
hardware is Little- or Big-Endian. The Assumption being that the compiler
will assumes that code is written in this way and will perform the necessary
byte-swapping dependant on the platform.

They are wrong. The “0x0000000f” used in your source code is
no more big-endian or little-endian than a “12345” or “3.73”.

Well, it’s big-endian if you intend it to mean a \0\0\0\xf
byte sequence. It’s little-endian if you intend it to mean
a \xf\0\0\0 byte sequence instead. It’s neither if you just
intend it to mean the number 15, without concern for how
the bytes will be laid out.

The confusion occurs because the English language, and thus
the C source code, uses a big-endian text representation.
We do this because somebody forgot to swap things around
when porting our number system from right-to-left languages.
See, endianness mistakes go back centuries.

Another reason for the confusion is that it is so darn
tempting to manually and crudely split 0x0000000f into
bytes by visually chopping it up. We are not so tempted
to do this with decimal constants! Hex constants are
treated much the same as decimal constants though.On Thu, 2005-07-21 at 18:38 +0200, Marc Daya wrote:

5

My thanks to all who responded to my question …
Your answers have been most helpful and I appreciate
your efforts.

.marc