Assume that unaligned access is not allowed unless we know otherwise

[smcv]

• _SDLNet_Read16: Be const-correct in unaligned code path

  We only read from areap here, we don't write to it.

• Always implement exported symbols for SDLNet_Write16 etc.

  It's easier to reason about the ABI if the same set of symbols is
  exported on all architectures, and always exporting these avoids
  breaking ABI when another architecture is found to require alignment.

  Regardless of whether we are performing unaligned access or not, we can
  implement the extern versions in terms of the inline versions.

• Assume that unaligned access is not allowed unless we know otherwise

  x86 architecturally allows unaligned access, but this is unusual:
  other CPU architectures generally do not. The safe assumption is that
  unaligned access on an unknown CPU architecture will either be very
  slow, or not work at all.

  Instead of assuming that unknown architectures are like x86, let's
  assume they are like ARM. This is true for riscv64, for example[1].

  x86 is the outlier here, and is the most likely to be extensively tested
  by SDL_net maintainers, so specifically detect x86 (using the predefined
  macros from gcc, clang and MSVC) and continue to use unaligned accesses
  there.

  [1] https://wiki.debian.org/ArchitectureSpecificsMemo#Alignment

[smcv]

A simple test program for this:

#undef _NDEBUG #include <assert.h> #include <stdio.h> #include <string.h> #include <SDL_net.h> int main (void) { char *buf = calloc(8, 8); int i; if (buf == NULL) { perror("calloc"); return 1; } buf[0] = 0x11; for (i = 1; i < 5; i++) buf[i] = 0x20 + i; buf[5] = 0x33; assert(SDLNet_Read16(buf + 1) == 0x2122); assert(SDLNet_Read32(buf + 1) == 0x21222324); SDLNet_Write16(0x4142, buf + 1); assert(buf[1] == 0x41); assert(buf[2] == 0x42); SDLNet_Write32(0x51525354, buf + 1); assert(buf[1] == 0x51); assert(buf[2] == 0x52); assert(buf[3] == 0x53); assert(buf[4] == 0x54); free(buf); return 0; }

[smcv]

Always implement exported symbols for SDLNet_Write16 etc.

I'd particularly like to get this commit included, because without this, I can't fix the alignment issue via downstream patches without introducing a Debian-specific ABI difference, which doesn't benefit anyone.