Mono Endianness

Question

with .NET things are fairly simple - it is all (including ARM ASFAIK) running little endian .

The question that I have is: what is happing on Mono and (potentially) big endian systems? Do the bits reverse (when compared to x86) in Int32 / Int64 structure or does the framework force little endian rule-set?

Thanks

It can't hide endianness, far too expensive. See BitConverter.IsLittleEndian. — Hans Passant, Mar 24 '11 at 23:13

score 13 · Answer 1 · edited May 23 '17 at 11:53

13

Your assertion that all MS .NET are little endian is not correct. It depends on the architecture that you are running on - the CLR spec says so:

From the CLI Annotated Standard (p.161) — Partition I, section 12.6.3: "Byte Ordering":

For data types larger than 1 byte, the byte ordering is dependent on the target CPU. Code that depends on byte ordering may not run on all platforms. [...]

(taken from this SO answer)

See this answer for more information on the internals of BitConverter and how it handles endianness.

edited May 23 '17 at 11:53

Community

1
1

answered Mar 24 '11 at 21:59

Oded

489,969
99
883
1,009

1

This brings in an interesting question: "..dependent on the target CPU..." so what happens with mono running on Little Endian windows running on top of Big Endian ARM CPU? [link](http://social.msdn.microsoft.com/Forums/en/windowsmobiledev/thread/04c92ef9-e38e-415f-8958-ec9f7c196fd3) MSFT Support forum – arthur Mar 24 '11 at 22:11
Isn't that the CLI spec rather than the CLR spec? (The part you've quoted says CLI.) All this demonstrates is that the CLI spec accommodates the possibility of a big-endian implementation. This would not contradict the proposition that all flavours of the CLR (i.e., Microsoft's implementation) are little-endian. And as far as I know, they all are. Are you aware of any supported Microsoft .NET implementation that's big-endian? (I think Rotor, aka SSCLI supported it, but that's not the CLR.) – Ian Griffiths Jul 08 '12 at 21:24

Meinersbur · Answer 2 · 2011-03-24T23:55:41.260

A list of behavioral changes I can think of at the moment (unchecked and incomplete):

IPAddress.HostToNetworkOrder and IPAddress.NetworkToHostOrder
Nearly everything in BitConverter
BinaryReader and BinaryWriter (EDIT: From documentation: "BinaryReader reads this data type in little-endian format.")
Binary serialization
Everything that reads and writes Unicode in default encoding from/to streams (UnicodeEncoding) (EDIT: Default is defined as little endian)

and of course every (runtime library) function using these.

Usually Microsoft doesn't mention endianness in their docs - with some strange exceptions. For instance, BinaryReader.ReadUInt16 is defined to read little endian. Nothing mentioned for the other methods. One may assume that binary serialization is always little-endian, even on big-endian machines.

Note that XNA on XBox360 is big-endian, so this not just a theoretical problem with Mono.

Sounds like I need to do some testing ... anyone has a good working QEMU image for ARM cpu with linux / mono installed on it? — arthur, Mar 26 '11 at 05:30

score 3 · Answer 3 · answered Mar 24 '11 at 21:55

3

c#/.Net does not make any claims on endian. int32/64 are atomic not structures.

answered Mar 24 '11 at 21:55

Richard Schneider

34,944
9
57
73

score 2 · Answer 4 · answered Mar 24 '11 at 21:54

2

As far as I know such conversion would happen outside the scope of your code and hidden to you. It's called "managed code" for some reasons, including such potential issues.

answered Mar 24 '11 at 21:54

Mario

35,726
5
62
78

1

There are a number of places where endianness affects the code. `BitConverter`, `Buffer.BlockCopy`, unsafe code, etc. – CodesInChaos Nov 28 '12 at 09:31

score 2 · Answer 5 · answered Mar 24 '11 at 22:14

2

To know if bytes are "reversed", just check BitConverter.IsLittleEndian:

if (BitConverter.IsLittleEndian)
{
    // reverse bytes
}

answered Mar 24 '11 at 22:14

Gabe

84,912
12
139
238

score 0 · Answer 6 · answered Mar 24 '11 at 21:56

0

Considering how similar .Net and Mono are by design, I'd say they probably handle endianness the same.

You can always test it by creating a managed int with a known value, then using reflection or marshalling to access the memory and take a look.

answered Mar 24 '11 at 21:56

ssube

47,010
7
103
140

The only problem that I have is access to a big endian system with framework on it:) What I'm specifically looking to do is to convert an integer to a byte array -- the array needs to be in a big endian order for things to work; Since the code might end up on a big endian system at some point, I'm trying to make sure I don't end up reversing the bytes when it is not needed. – arthur Mar 24 '11 at 22:01

Mono Endianness

6 Answers6