Hi Junio, On Mon, 9 Nov 2020, Junio C Hamano wrote: > "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. I would feel a bit more comfortable reintroducing the part that specifically checks for x86, x86_64 and ARM64, for the reasons I outlined in my reply to a previous version of this patch: just because the MSVC versions we can currently use to build Git currently only supports little endian does not mean that all future versions will do. Point in reference: you can build Linux applications in Visual Studio like _right now_ [*1*]. Ciao, Dscho Footnote *1*: It currently uses GCC, but who says it always will? https://docs.microsoft.com/en-us/cpp/linux/cmake-linux-project
