Runtime: Do we need #if BIGENDIAN?

[danmosemsft]

These came over from desktop and we apparently never define it.

Searching 11694 files for "#if.*BIGENDIAN" (regex)

C:\git\corefx\src\Common\src\System\Net\ByteOrder.cs:
   11          public static ushort HostToNetwork(this ushort host)
   12          {
   13: #if BIGENDIAN
   14              return host;
   15  #else
   ..
   20          public static uint HostToNetwork(this uint host)
   21          {
   22: #if BIGENDIAN
   23              return host;
   24  #else
   ..
   50          public static uint NetworkBytesToNetworkUInt32(this byte[] bytes, int index)
   51          {
   52: #if BIGENDIAN
   53              return unchecked((uint)(bytes[index + 3] | (bytes[index + 2] << 8) | (bytes[index + 1] << 16) | (bytes[index] << 24)));
   54  #else
   ..
   59          public static void NetworkToNetworkBytes(this uint host, byte[] bytes, int index)
   60          {
   61: #if BIGENDIAN
   62              bytes[index] = (byte)(host >> 24);
   63              bytes[index + 1] = (byte)(host >> 16);

C:\git\corefx\src\Common\src\System\Net\SocketAddressPal.Windows.cs:
   23          public static unsafe void SetAddressFamily(byte[] buffer, AddressFamily family)
   24          {
   25: #if BIGENDIAN
   26              buffer[0] = unchecked((byte)((int)family >> 8));
   27              buffer[1] = unchecked((byte)((int)family));

C:\git\corefx\src\System.Net.NameResolution\src\System\Net\NameResolutionPal.Windows.cs:
   80                  //
   81                  IPAddressToAdd = Marshal.ReadInt32(nativePointer);
   82: #if BIGENDIAN
   83                  // IP addresses from native code are always a byte array
   84                  // converted to int.  We need to convert the address into
   ..
  175              int addressAsInt = unchecked((int)address.GetAddress());
  176  
  177: #if BIGENDIAN
  178              // TODO dotnet/runtime#15066: above code needs testing for BIGENDIAN.
  179  

C:\git\corefx\src\System.Net.Primitives\src\System\Net\IPAddress.cs:
  357          public static long HostToNetworkOrder(long host)
  358          {
  359: #if BIGENDIAN
  360              return host;
  361  #else
  ...
  367          public static int HostToNetworkOrder(int host)
  368          {
  369: #if BIGENDIAN
  370              return host;
  371  #else
  ...
  377          public static short HostToNetworkOrder(short host)
  378          {
  379: #if BIGENDIAN
  380              return host;
  381  #else

C:\git\corefx\src\System.Net.Sockets\src\System\Net\Sockets\SocketPal.Windows.cs:
  520              }
  521  
  522: #if BIGENDIAN
  523              ipmr.MulticastAddress = (int) (((uint) ipmr.MulticastAddress << 24) |
  524                                             (((uint) ipmr.MulticastAddress & 0x0000FF00) << 8) |
  ...
  625              }
  626  
  627: #if BIGENDIAN
  628              ipmr.MulticastAddress = (int) (((uint) ipmr.MulticastAddress << 24) |
  629                                             (((uint) ipmr.MulticastAddress & 0x0000FF00) << 8) |

12 matches across 5 files

[danmosemsft]

@CIPop @davidsh

[ghost]

There are still times I'm in the position of having to write endian-specific code. At those times, I don't want to leave a silent landmine behind. I want a protocol to make sure the code does the right thing or throws or asserts or breaks the build or paint a message on the screen saying "Big endian. Warranty voided." "#if BIGENDIAN" works well enough for that - it costs nothing and its meaning is clear.

Anything other than silently returning the wrong result.

[danmosemsft]

OK, as long as we're all clear that it's not getting compiled let alone tested.

[CIPop]

The code was ported as-is and as you mention is not tested on a big-endian machine. Network data should be handled via host to network (and reverse) APIs.
I wouldn't trust the fact that only these areas would be affected by switching to big-endian. I too agree with @AtsushiKan and see more harm in removing the statements.

@danmosemsft The question remains: do we want to support bi-endian machines in their big-endian mode (e.g. ARM) or older big-endian machines?

[danmosemsft]

I agree this seems like a case where keeping dead code makes sense.

@gkhanna79 for question about supporting big-endian mode.

[jkotas]

.NET Core does not run on any big endian machines right now, and nobody has a crystal ball to tell whether it will change in future.

Mono does run on big endian machines and there is work in progress to use corefx sources in Mono. However, Mono prefers runtime checks for it instead of ifdefs, see for example https://github.com/mono/mono/commit/92cec4692a244dc11117a5931cf6f059dbd1ad24

[danmosemsft]

OK closing since we will keep as is.