There are arguments either way, but one point is that in a little-endian system, the address of a given value in memory, taken as a 32, 16, or 8 bit width, is the same.
In other words, if you have in memory a two byte value:
taking that '16' as a 16-bit value (c 'short' on most 32-bit systems) or as an 8-bit value (generally c '...
I always wonder why someone would want to store the bytes in reverse order.
Big-endian and little-endian are only "normal order" and "reverse order" from a human perspective, and then only if all of these are true...
You're reading the values on the screen or on paper.
You put the lower memory addresses on the left, and the higher ones on the right.
OK, here's the reason as I've had it explained to me: Addition and subtraction
When you add or subtract multi-byte numbers, you have to start with the least significant byte. If you're adding two 16-bit numbers for example, there may be a carry from the least significant byte to the most significant byte, so you have to start with the least significant byte ...
... why would I rearrange the bytes ... when I already know that both, server and client run on little endian? Thats just unnecessary work to do.
It's only unnecessary if you can guarantee your code will always run on little-endian architectures. If you intend for it to have a long life, it's worth the extra effort to avoid disturbing well-proven code a ...
I'd argue that it's not so much won as ceased to matter. ARM which makes up basically all of the mobile market is bi-endian (oh, the heresy!). In the sense that x86 basically "won" the desktop market I suppose you could say that little endian won but I think given the overall code depth (shallow) and abstraction (lots) of many of today's applications, it's ...
I've always thought that it's defined the wrong way, and that's also the tip to remember it. As a non-native English speaker, I see "end" as the opposite of "start" (although obviously "end" can mean either end - the start end, or the end end). Anyway, I just remember that "it's defined the wrong way" :)
In big endian, the most significant (biggest) byte is ...
With 8 bit processors it was certainly more efficienct, you could perform an 8 or 16bit operation without needing different code and without needing to buffer extra values.
It's still better for some addition operations if you are dealing a byte at a time.
But there is no reason that big-endian is more natural - in English you use thirteen (little endian) ...
Endianness for binary (base 2) is no different than endianness for any other base.
Without a specification telling you which side the most significant and least significant decimals were, you wouldn't know whether
is one-thousand-two-hundred-and-thirty-four or four-thousand-three-hundred-and-twenty-one.
Note for additional curiosity that "twenty-one"...
"Is this right that little endian processors read the memory addresses
from highest to the lowest address and where as a big endian
processors suppose to read them from lowest to the highest address?"
No, that would just be an implementation detail of the memory chip, which would not make any difference for how you use the system.
In the little endian ...
The Japanese date convention is "big endian" - yyyy/mm/dd. This is handy for sorting algorithms, which can use a simple string-compare with the usual first-character-is-most-significant rule.
Something similar applies for big-endian numbers stored in a most-significant-field-first record. The significance order of the bytes within the fields matches the ...
Nobody else has answered WHY this might be done, lots of stuff about consequences.
Consider an 8 bit processor which can load a single byte from memory in a given clock cycle.
Now, if you want to load a 16 bit value, into (say) the one and only 16 bit register you have - ie the program counter, then a simple way to do it is:
Load a byte from the fetch ...
It's your protocol.
You can't safely ignore it. But you can safely label it. You control the client and the server. You control the protocol. Doesn't it make sense not to care whether it's big-endian or little-endian so long as you know whether both sides agree?
This means overhead. Now you have to mark your endianness somehow. Do that, and I can read it ...
Big-endian numbers start at the "big end".
Little-endian numbers start at the "little end".
Both are an allusion to the issue of where to start eating your egg, as per Gulliver's Travels.
In this case, "end" is not the opposite of start, it just means any extreme of a (rope|string|number|sequence), thus them not being called "big finishian" or "little ...
The best way to remember this is that civilized peoples seek out variety and hence eat their eggs differently than they order their numbers. Whereas we write decimal digits starting at the big digits first (big endian), we eat soft boiled eggs from the little end (little endian).
You are right that using different setups for your tests can increase the chance of accidentally stumbling on some bugs. However, you should consider whether setting up a another testing rig makes sense from a business perspective of things – I suspect you want to sell or distribute useful code, rather than crafting The Perfect Code in your ivory tower.
So, my question is: Can I safely ignore the endianess and just send little-endian data?
There are two interpretations of that:
If you design your applications / protocols to always1 send little-endian, then you are NOT ignoring endianess.
If you design your applications / protocols to send / receive whatever the native endianess is, then they will work as ...
The order in which bit fields are placed in an integer is independent of the order in which bytes are placed in an integer. Both are implementation details. That is generally not a problem, because memory is only byte addressable, and all hardware preserves the value of a byte during transmissions.
Yet, while bit and byte ordering are theoretically ...
Seems there is a principal misconcept here, because, citing you,
The (known) float 8.03 generated the bytes 56,46,48,51
the sequence 56,46,48,51 is 8.03 in text (ASCII), but not the binary representation according to widely used standards as IEEE754.
With IEEE754 4-byte binary, 8.03 is represented as 65,0,122,225 (in big-endian order) or 225,122,0,65 (in ...
Timothy's answer is correct, but not complete enough to understand what is going on here.
Strings are a sequence of bytes; there is no "endianness" for strings because bytes have no endianess.
Endianess refers to the byte order that is used to store larger multiple-byte items in memory.
So, for big endian the most significant byte is stored at the ...
I think you've probably covered much of this already, but I'd give some further consideration to:
Low memory environment, e.g. mobile with small RAM or embedded devices. While your current customers may not need this, who knows if your library is suddenly in huge demand for engine management systems or home routers.
Highly concurrent environment, e.g. more ...
No, nobody has won. We as a species we have failed to standardize the order in which we store our bytes, along with the direction we write and the side of the street we drive on.
As a consequence, anyone who wants to transfer data between two different systems over a network or in a file, has only about a 50% chance of the reasonable initial version of ...
Endians only really matters when you are transferring binary data systems.
With the advancement of processor speed (and much much lower cost of storage) binary data interfaces are becoming rarer so you don't notice them at the application layer. You are either using a textual transfer format (XML/JSON) or you are using data layer abstraction that takes care ...
Note that 'network byte order' is big endian, so if you are transmitting any standardized structures, you will need to do that conversion.
Generally, most people avoid this issue by transmitting data in a textual form (like XML or JSON).
There are no major, very popular chipsets using big endian, so it may not be a pragmatic problem for you. But things ...
jimwise made a good point. There is another issue, in little endian you can do the following:
num += data[i]<<i*8;
num = *(int*)&data; //is interpreted as
mov dword data, num ;or something similar it has been some time
More straight forward for programmers which are not affected by the ...
The answer is: it depends.
If you're sharing data with another platform, or (de)serializing some binary format with defined endianness, then you need to match that platform's or format's endianness.
Assuming that target endianness is well defined (and different from your native endianness), that will tell you what conversions you need.
Oh, and I'd suggest ...
The standard BSD networking stack in C has the hton/ntoh functionality ( network-to-host/host-to-network ) which expand to no-ops on network-native machines (big endian).
You'd need your own counterparts to these for the scenario in which network-native byte order is little endian.
That's the robust way to do it.
It'd be unconventional, but I see nothing ...
Endianness is not the only consideration. There is the size of integers, there is packing of structs that you might want to send or receive, and so on.
You can ignore all this. Nobody can force you. On the other hand, the safe and reliable way is to document an external format, and then write code that will read or write the external format correctly, no ...
Various protocols used to transmit data between servers use little endian numbers:
See https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats, for details on various formats some of which have little-endian numbers, and some have big-endian numbers.
There is absolutely nothing wrong with using a protocol ...
Endianness applies to number types (like int/long/double...). You stored a string (an array/list of characters). Therefore the bytes of your string are stored in order of appearance regardless of the processors endianness.