Use compiler macros for endianness

[kmilos]

Supersedes #2668 as not fully portable.

Using the same form as in include/config.h

[ghost]

👇 Click on the image for a new way to code review

Legend

[kevinbackhouse]

Is this macro (__LITTLE_ENDIAN__) sometimes defined when __BYTE_ORDER__ isn't? If so, maybe this logic should be moved to isBigEndianPlatform. I.e. add this to the beginning of isBigEndianPlatform:

#if defined(__BIG_ENDIAN__)
  return true;
#elif defined(__LITTLE_ENDIAN__)
  return false;
#elif ...

[kmilos]

__LITTLE_ENDIAN__ is our own macro (potentially) defined in config.h.

Everything else comes from the compiler. AFAICT, there is no definition of __BIG_ENDIAN__.

[kmilos]

Is this macro (__LITTLE_ENDIAN__) sometimes defined when __BYTE_ORDER__ isn't?

Potentially on WIN32 and MSVC (which AFAIK does not define __BYTE_ORDER__):

exiv2/include/exiv2/config.h

Line 43 in 50648dd

#if defined(_WIN32) || defined(__CYGWIN__)

[kmilos]

@kevinbackhouse I'm now leveraging these as well.

[codecov]

Codecov Report

Merging #2688 (64fe778) into main (50648dd) will not change coverage.
The diff coverage is 100.00%.

❗ Current head 64fe778 differs from pull request most recent head 7930039. Consider uploading reports for the commit 7930039 to get more accurate results

@@           Coverage Diff           @@
##             main    #2688   +/-   ##
=======================================
  Coverage   63.90%   63.90%           
=======================================
  Files         103      103           
  Lines       22313    22313           
  Branches    10799    10799           
=======================================
  Hits        14260    14260           
  Misses       5828     5828           
  Partials     2225     2225           

Impacted Files	Coverage Δ
src/image.cpp	70.19% <100.00%> (ø)

[neheb]

For Windows, it's always little endian AFAIK.

[kmilos]

For Windows, it's always little endian AFAIK.

Yes, and we set __LITTLE_ENDIAN__ in config.h in that case, as I linked above.

[neheb]

Anyway, a lot of work for this function. Would be nice to just use 84e45a3

Requires GCC9 though.

[kmilos]

Requires GCC9 though.

I've been fine with this all along. 😉

[kmilos]

@neheb I'm going to merge this for now as I believe it is more portable, so please rebase your change for eventual GCC 9 (and Clang 9/10?) bump...