Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When teaching recently about the Big vs. Little Endian battle, a student asked whether it had been settled, and I realized I didn't know. Looking at the Wikipedia article, it seems that the most popular current OS/architecture pairs use Little Endian but that Internet Protocol specifies Big Endian for transferring numeric values in packet headers. Would that be a good summary of the current status? Do current network cards or CPUs provide hardware support for switching byte order?

share|improve this question

2 Answers 2

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 much less of an issue than it used to be. I don't recall endianness really coming up in my Computer Architecture class.

I suspect that many developers aren't even aware of endianness or why it's important. Because for the vast (and I mean vast) majority it's utterly irrelevant to their daily working environment. This was different 30 years ago when everyone was coding much closer to the metal as opposed to manipulating text files on a screen in fancy and dramatic ways.

My general suspicion is that Object Oriented Programming was the beginning of the end of caring about endianness since the layers of access and abstraction in a good OO system hide implementation details from the user. Since implementation includes endianness, people got used to it not being an explicit factor.

Addendum: zxcdw mentioned portability being concern. However, what has arisen with a vengeance in the last 20 years? Programming Languages built on virtual machines. Sure the virtual machine endianness might matter but it can be made very consistent for that one language to the point where it's basically a non-issue. Only the VM implementors would even have to worry about endianness from a portability standpoint.

share|improve this answer
There are still many very relevant domains in which it matters, for example when writing any form of portable code. Infact, where it probably does not matter is when writing non portable code which is tied to a platform. –  zxcdw Sep 23 '12 at 18:48
@zxcdw which leads us directly to the army of virtual machine languages out there... I hadn't thought of that. –  World Engineer Sep 23 '12 at 19:53
Your addendum is not entirely true (and neither do I agree with @zxcdw): endianness matters only when translating between multibyte integers and byte streams, and becomes a problem when it's done implicitly and varies between platforms. Most modern languages (whether VM-based or not) achieve portability by having you do it rarely (with integers as an opaque datatype), and then have endianness either specified independant of platform, or explicitly chosen by the programmer. –  Michael Borgwardt Sep 23 '12 at 20:06
@MichaelBorgwardt The said translation between multibyte integers may happen when simply running the software on another platform. This is a major concern when working with native code when platform isn't fixed. Of course, considering that it's 2012 and more and more people are moving to higher levels of abstraction this issue can be considered fading away and considered insignificant for huge, huge majority of programmers. –  zxcdw Sep 23 '12 at 20:20
@MichaelBorgwardt ARM does arium.com/pdf/Endianness.pdf –  World Engineer Sep 23 '12 at 20:35

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 of the translation for you (so you don't even notice that there is a translation).

But when you are coding at the binary data layer you do notice and it is very important. For example When I worked at VERITAS (Symantec now) I was building software that was being built on 25 different hardware platforms (not only big/little endian there are other types).

share|improve this answer
My students have also developed for mobile phones and used cloud computing, so they know the world is not PCs and Macs. –  espertus Sep 24 '12 at 0:56
@Loki - it's possible to serialize and de-serialize without knowing the endian of the machine. You only really need to know the byte-ordering of the data in the files/streams/whatever. For example, (char) (x & 0xFF) in C gives you the least significant byte irrespective of endian issues, assuming only that a byte is 8 bits. I've designed binary file formats without knowing the machines that the software would run on - I basically chose an endian ordering for the file format without caring about the hardware. –  Steve314 Sep 24 '12 at 4:50
@espertus: Sure possible. –  Loki Astari Sep 24 '12 at 5:16
@Steve314: Yes of course you can. When you are working on the "Binary Data Layer" you can devise whatever scheme you want to serialize your data and it is not hard to devise schemes that that are portably. Though personally I would not bother to re-invent a wheel that has been built and well tested since the 60's. Look up `h2nl and family. this family of functions provide a portable (standard) way of doing things that is optimal for your platform. –  Loki Astari Sep 24 '12 at 5:23

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.