tags:

views:

186

answers:

6

Am I right in thinking that endianess is only relevant when we're talking about how to store a value and not relevant when copying memory?

For example

if I have a value 0xf2fe0000 and store it on a little endian system - the bytes get stored in the order 00, 00, fe and f2. But on a big endian system the bytes get stored f2, fe, 00 and 00.

Now - if I simply want to copy these 4 bytes to another 4 bytes (on the same system), on a little endian system am I going to end up with another 4 bytes containing 00, 00, fe and f2 in that order?

Or does endianness have an effect when copying these bytes in memory?

+3  A: 

no when working on the same machine you don't have to worry about endianess, only when transferring binary data between little and big endian machines

Tristan
Which "storing to a file" is a subset of - since you don't know if the app reading the said file will run on little-endian Windows PC or a big-endian iPhone.
slebetman
... or any other form of binary serialization.
Michael
+4  A: 

Answering the question title.

Assume 'int' to be of 4 bytes

union{
   unsigned int i;
   char a[4];
};

// elsewhere
i = 0x12345678;
cout << a[0];   // output depends on endianness. This is relevant during porting code
                // to different architectures

So, it is not about copying (alone)? It's about how you access?

It is also of significance while transferring raw bytes over a network!.

Here's the info on finding endianness programatically

Chubsdad
+7  A: 

Endianness is only relevant in two scenarios

  1. When manually inspecting a byte-dump of a multibyte object, you need to know if the bytes are ordered in little endian or big endian order to be able to correctly interpret the bytes.
  2. When the program is communicating multibyte values with the outside world, e.g. over a network connection or a file. Then both parties need to agree on the endianness used in the communication and, if needed, convert between the internal and external byte orders.
Bart van Ingen Schenau
+2  A: 

Basically, you have to worry about endianess only when you need to transfer binary data between architectures which differ in endianess.

However, when you transfer binary data between architectures, you will also have to worry about other things, like the size of integer types, the format of floating numbers and other nasty headaches.

sbi
@sbi, right, but if endianness of a system affects how a value is stored, and I care about the stored value's byte order in memory then in that instance, I need to care about endianness.
BeeBand
@sbi, maybe I need to change the title to "should I care about endianness when copying memory?" - maybe the current title is misleading.
BeeBand
@BeeBand: My answer answers that, too: as long as you don't copy between architectures with differing endianess...
sbi
@sbi, yes. Apologies, your answer does indeed answer that question, albeit implicitly :).
BeeBand
@BeeBand: `:-)`
sbi
+3  A: 

memcpy doesn't know what it is copying. If it has to copy 43 61 74 00, it doesn't know whether it is copying 0x00746143 or 0x43617400 or a float or "Cat"

MSalters
A: 

Yes, you are correct thinking that you should be endianness-aware when storing or communicating binary values outside your current "scope". Generally you dont need to worry as long as everything is just inside your own program. If you copy memory, have in mind what you are copying. (You could get in trouble if you store long values and read ints).
Have a look at htonl(3) or books about network programming for some good explanations.

MattBianco