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

[Junio C Hamano <gitster@pobox.com>]

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