"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > On 2020-11-10 at 00:31:27, Jeff King wrote: >> 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]. So, The only versions of MSVC that support big-endian are too ancient and do not understand some C99 features we use in our codebase, so it is unnecessary... would be sufficient? > 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. Maybe controversial, but worth at least laying the ground rules ahead of time? Do we have any specific feature we avoid only due to portability concerns? Declaring an identifier in the first part of for() is the only thing that comes to my mind, but there may be others. I think we should consider how well each individual feature is supported by systems we care about as we feel the need. Thanks.
