Re: [PATCH 0/2] linux: Keep time64 stat layout independent of feature macros

Thanks for squashing this together with the generic-header fix.

I ran an independent cross-ABI compile-time layout check against your
squashed commit (ecf95727a787) versus pre-fix master (d6031665).  The
probe includes the actual bits/struct_stat.h and
bits/struct_stat_time64_helper.h from each commit and records sizeof and
16 member offsets of struct stat for _TIME_BITS=64
_FILE_OFFSET_BITS=64 in five feature modes: default (_GNU_SOURCE),
POSIX.1-1996, POSIX.1-2001, POSIX.1-2008, and X/Open 600.  Targets are
compiled with clang --target; arc and or1k are modeled on the
layout-equivalent i386 (LE, alignof(long long)==4) and powerpc (BE,
alignof(long long)==8) backends since clang has no ARC/OpenRISC backend.
The i386 model reproduces the sizes and offsets measured against real
glibc 2.44 headers.

Result: the layout is feature-mode-invariant on every target after your
change.

  target    pre-fix strict modes vs default          post-fix
  i386      size 116 vs 108, nsec order flipped      all modes identical (108)
  arm       size 120 vs 112                          all modes identical (112)
  powerpc   size 120 vs 112                          all modes identical (112)
  mips o32  size 120 vs 112                          all modes identical (112)
  mipsel    size 120 vs 112, nsec order flipped      all modes identical (112)
  riscv32   already invariant                        all modes identical (128)
  arc       size 116 vs 128, timestamps 12 apart     all modes identical (128)
  or1k      nsec on wrong side of padding            all modes identical (128)

The generic-header fix lands exactly as your commit message describes:
arc is now byte-identical to riscv32 on all measured values, and or1k
matches riscv32 except the nanosecond fields at +12, the correct
big-endian side.  The default-mode layout is unchanged on every target,
so the fix only moves the strict modes onto the existing ABI.  riscv32
was already invariant before the fix, consistent with your analysis.

Caveats: this is a compile-time layout model, not configured cross
builds, and the arc/or1k rows rest on the backend equivalence noted
above.  microblazeel is not covered (no clang backend); as a
helper-family port without its own endian include it follows the mipsel
pattern.

Matthias