patchcompat/bswap.h: Simplify MSVC endianness detection

> Modern MSVC or Windows versions don't support big-endian, so it's
> unnecessary to consider architectures when using it.
> 
> Signed-off-by: Daniel Gurney <dgurney99@gmail.com>
> ---
>  compat/bswap.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/compat/bswap.h b/compat/bswap.h
> index c0bb744adc..72f225eaa8 100644
> --- a/compat/bswap.h
> +++ b/compat/bswap.h
> @@ -74,7 +74,7 @@ static inline uint64_t git_bswap64(uint64_t x)
>  }
>  #endif
>  
> -#elif defined(_MSC_VER) && (defined(_M_IX86) || defined(_M_X64))
> +#elif defined(_MSC_VER)
>  
>  #include <stdlib.h>
>  

> 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).

> 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].

> 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.

> "brian m. carlson" <sandals@crustytoothpaste.net> 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.

> On 10/11/2020 16:04, Johannes Schindelin wrote:
> > 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
>
> When it comes to building C++ code MSVC uses Microsoft's C++ Standard Library,
> and one of its stated non-goals[1] is being ported to other systems. I assume
> the same applies for their C library. Therefore to me a scenario where a
> future version of MSVC would build non-Windows code, let alone for a
> big-endian architecture, seems extremely unlikely.

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> As a maintainer, I am less concerned about the "result today" than I am
>> about keeping things easy and effortless to maintain. One of your patches
>> accomplishes that. The other one made it into `next`:
>> https://github.com/git/git/commit/91a67b86f77
>
> I do not think reverting it and requeuing
>
> https://lore.kernel.org/git/20201107221916.1428757-1-dgurney99@gmail.com/
>
> would help future folks why we ignore _MSC_VER as any sign usable to
> detect endianness, so I'd prefer to see a patch *on top* of 1af265f0
> (compat/bswap.h: simplify MSVC endianness detection, 2020-11-08),
> which is 91a67b86f77^2, that explains why we prefer to list archs
> explicitly in its log message, which would be the primary value of
> that commit.
>
> Something along this line, perhaps?
>
> -- >8 --
>
> Subject: compat/bswap.h: do not assume MSVC is little-endian only
>
> Earlier, with 1af265f0 (compat/bswap.h: simplify MSVC endianness
> detection, 2020-11-08), we tried to simplify endianness detection
> used in compat/bswap.h by assuming that any version Git compiled by
> MSVC (detected by _MSC_VER preprocessor macro) is meant to run on
> little endian boxes, as the versions of old MSVC that support m68k
> and MIPS do not support some C99 features used in the codebase
> anyway.
>
> While it might hold true that modern versions of Windows are all
> little-endian, MSVC is and/or can be ported to build for big-endian
> boxes, so tying _MSC_VER with endianness is a bit too restrictive.
>
> Let's go back to the old way to use _MSC_VER to learn what
> preprocessor macros compiler uses to tell us which arch we are
> building for, and list these arches that are little-endian
> explicitly.
>
> ... signed-off-by from you and helped-by from others ...
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>     diffstat
>     patch

> Junio C Hamano <gitster@pobox.com> writes:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >> As a maintainer, I am less concerned about the "result today" than I am
> >> about keeping things easy and effortless to maintain. One of your patches
> >> accomplishes that. The other one made it into `next`:
> >> https://github.com/git/git/commit/91a67b86f77
> >
> > I do not think reverting it and requeuing
> >
> > https://lore.kernel.org/git/20201107221916.1428757-1-dgurney99@gmail.com/
> >
> > would help future folks why we ignore _MSC_VER as any sign usable to
> > detect endianness, so I'd prefer to see a patch *on top* of 1af265f0
> > (compat/bswap.h: simplify MSVC endianness detection, 2020-11-08),
> > which is 91a67b86f77^2, that explains why we prefer to list archs
> > explicitly in its log message, which would be the primary value of
> > that commit.
> >
> > Something along this line, perhaps?
> >
> > -- >8 --
> >
> > Subject: compat/bswap.h: do not assume MSVC is little-endian only
> >
> > Earlier, with 1af265f0 (compat/bswap.h: simplify MSVC endianness
> > detection, 2020-11-08), we tried to simplify endianness detection
> > used in compat/bswap.h by assuming that any version Git compiled by
> > MSVC (detected by _MSC_VER preprocessor macro) is meant to run on
> > little endian boxes, as the versions of old MSVC that support m68k
> > and MIPS do not support some C99 features used in the codebase
> > anyway.
> >
> > While it might hold true that modern versions of Windows are all
> > little-endian, MSVC is and/or can be ported to build for big-endian
> > boxes, so tying _MSC_VER with endianness is a bit too restrictive.
> >
> > Let's go back to the old way to use _MSC_VER to learn what
> > preprocessor macros compiler uses to tell us which arch we are
> > building for, and list these arches that are little-endian
> > explicitly.
> >
> > ... signed-off-by from you and helped-by from others ...
> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
> > ---
> >     diffstat
> >     patch
>
> Daniel's patch adds _M_ARM64 to the list, but do we need to do
> anything further to tell the endian on such a bi-endian arch, or
> does MSVC only support little-endian for that architecture?

> And perhaps it is worth documenting in the log, perhaps
>
> 	... that are little-endian explicitly.  Note that ARM64 is
> 	bi-endian in nature but we treat it little-endian as MSVC
> 	does not treat the arch as bi-endian.
>
> or something like that at the end (I do not know what MSVC actually
> does---just illustrating the level of details I expect in the
> explanation).

> > > 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).

> 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.