MemoryMarshel.Cast is endian-safe?

[Flithor]

If I use MemoryMarshel.Cast on different endian platform to cast same Span<byte>, will I got the same result?

For example:
here is a byte array of a date, it's got on little-endian platform:
{ 0xE5, 0x07, 0x03, 0x11 }
[0xE5, 0x07] => 2021
[0x03] => 3
[0x11] => 17
And I have a DateStruct:

[StructLayout(LayoutKind.Sequential, Pack = 1)]
public struct DateStruct
{
    public ushort year;
    public byte month;
    public byte day;
}

Cast this byte array to struct:

var bytes = new byte[] { 0xE5, 0x07, 0x03, 0x11 };
var span = new Span<byte>(bytes);
var date = MemoryMarshal.Cast<byte, DateStruct>(span)[0];

So, If I run it on a big-endian platform, the value of date.year will be 2021 or 58631?

I had read this: https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.memorymarshal.cast but still a bit confused.

[alexrp]

Fundamentally, you're just casting a byte* to a DateStruct*. Whether the year field will make sense depends entirely on what's in bytes. The byte array you provided happens to have the correct ordering for a little endian system. If you run the same code with that same byte array on a big endian system, year will be 58631.

You should basically only do this if you know with certainty the endianness of the system that produced the byte array.

[Flithor]

Oh I see

low=>|01|02|03|04|=>high
on little-endian platform, it's read from low to high, will got 0x01020304
on big-endian platform, it's read from high to low, will got 0x04030201

[gfoidl]

Have a look at BinaryPrimitives.
With a check BitConverter.IsLittleEndian you can use the suitable methods.

[Flithor]

Awesome!

But looks I can't use it when casting, maybe I need to pack my struct and process it before use.

[gfoidl]

Let's have look what's going on here:
The byte-sequence 0xE5, 0x07, 0x03, 0x11 doesn't change it's physical order whether it's LE (little endian) or BE (big endian). When it's casted to the DateStruct the same physical order of bytes remain, but now these bytes are interpreted as the given DateStruct (side note: that's why C++ has the reinterpret_cast operator).
You can think like that DateStruct is "overlayed" to the byte-sequence.

This struct has three fields, one ushort and two bytes. And this interpretation is different on LE and BE only for the multi-byte size fields. For single-byte sized fields it doesn't matter which endiannes is used.

Interpretation on LE:
ushort year -> 0x07E5 (as the least significant byte is stored first)
byte month -> 0x03
byte day -> 0x11

Interpretation on BE:
ushort year -> 0xE507 (as the most significant byte is stored first)
byte month -> 0x03
byte day -> 0x11

Remember: thy physical order of bytes in memory is still the same, it's just about interpreting the values.

This means on LE and BE engines you get the same values for month and day, but different values for year.
0x07E5 <-> 2021
0xE507 <-> 58631

The size of the struct is 4, the same as for int, so it might be tempting on BE to read it as int, then reverse the endianess, but this won't work as the bytes of the whole struct are reversed and year is still the first ushort field.

So you can do this:

static DateStruct ReadDate(ReadOnlySpan<byte> span)
{
    DateStruct date = MemoryMarshal.Cast<byte, DateStruct>(span)[0];

    if (BitConverter.IsLittleEndian)
    {
        return date;
    }

    date.year = BinaryPrimitives.ReverseEndianness(date.year);
    return date;
}

(the JIT will dead-code eliminate the not-taken branch as BitConverter.IsLittleEndian is treated at compile-time constant and for BE will emit a effienct ror instruction on x86).

Or you read the fields of the struct solely with the methods from BinaryPrimitives without casting.
Depends on what measures you have.

Side note: as I mentioned C++ reinterpret_cast before, the "direct equivalent" in .NET is Unsafe.As<TFrom, TTo>, but MemoryMarshal.Cast<TFrom, TTo> is safer and you can operate on spans instead of refs.