Re: [PATCH 1/2] y2038: Adjust struct __stat64_t64 to be usable by redirected {f}stat{at} calls

[Joseph Myers <joseph@codesourcery.com>]

On Tue, 13 Oct 2020, Lukasz Majewski wrote:

> When glibc port with __WORDSIZE==32 and __TIMESIZE!=64 (e.g. armv7) will
> use redirected calls to {f}stat{at}64_time64 functions, it will accept
> the struct __stat64_t64 as its argument.
> 
> To avoid errors related to proper data placement after casting from
> struct __stat64_t64 to struct stat{64} it is necessary to add some missing
> padding and update type of {__}st_ino member.

When redirecting to those functions, the definitions of struct stat / 
struct stat64 should automatically change as a result of the _TIME_BITS=64 
definition so that they match the definitions of the __stat64_t64 type - 
just as _FILE_OFFSET_BITS=64 results in changes to the content of struct 
stat.

I believe the design is that __stat64_t64 has an architecture-independent 
layout that is never required to match any particular kernel layout 
because translation (typically from statx) will always occur in userspace.

Note that struct_stat_time64.h is currently an *uninstalled* header, 
despite the name of the multiple-include guard in the header, and despite 
the testing of feature test macros within the header (which only makes 
sense for installed headers); it's not a bits/ header at present.

Maybe there should be some indirection so that the installed version of 
struct_stat_time64.h defines a macro with all the contents of 
__stat64_t64, so that all the many architecture-specific 
bits/struct_stat.h headers can just use that macro to get the right 
contents when _TIME_BITS=64 rather than needing to duplicate the structure 
contents (at least twice per header, for both stat and stat64).  But I 
don't think any change to the layout of __stat64_t64 is indicated, because 
there should always be explicit conversions between different layouts.

-- 
Joseph S. Myers
joseph@codesourcery.com