Re: [PATCH v2] compat/bswap.h: simplify MSVC endianness detection

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Nov 10, 2020, 02:36 UTC
Message-ID: <20201110023620.GH6252@camp.crustytoothpaste.net>
In-Reply-To: <20201110003127.GA1268480@coredump.intra.peff.net>

On 2020-11-10 at 00:31:27, Jeff King wrote:

Show 7 quoted lines

> On Sun, Nov 08, 2020 at 11:57:41AM +0200, Daniel Gurney wrote:
> 
> > Modern MSVC or Windows versions don't support big-endian, so it's
> > unnecessary to consider architectures when using it.
> 
> This made me wonder if we support any non-modern versions (which would
> be negatively impacted).

I'm pretty sure we don't. As I said, we're using several C99 features and that version precedes the C99 standard (and 1999).

> From the earlier thread at [1], it sounds like probably not, but I
> wonder if we can offer a stronger argument there (or just define
> "modern" a little more clearly).

According to Wikipedia[0]:

  Visual C++ 2013 [12.0] finally added support for various C99 features
  in its C mode (including designated initializers, compound literals,
  and the _Bool type), though it was still not complete. Visual C++ 2015
  further improved the C99 support, with full support of the C99
  Standard Library, except for features that require C99 language
  features not yet supported by the compiler.

The version mentioned that supported MIPS, Alpha, and m68k was Visual C++ 2.0 RISC Edition. While Wikipedia doesn't mention its release date, its successor, Visual C++ 4.0, was released in 1995. The m68k version ran on Macs using those processors, and Apple abandoned m68k for PowerPC in 1994[1].

I'm entirely comfortable with requiring that people use a compiler and operating system newer than 25 years old to compile Git correctly. As I've said or implied in previous threads, I'm also fine requiring C99 (vendors having had over two decades to implement it) and only supporting OSes with vendor security support, although obviously these latter two items are much more controversial.

I'm fine leaving the commit message as it stands, given the brevity of the patch and that in the technology field, the affected versions are not in any way "modern," but of course I wouldn't object to a reroll. It's fine, should that happen, to include any of this email in the commit message.

[0] https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B [1] https://en.wikipedia.org/wiki/Macintosh

-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US