Re: [PATCH] y2038: Reorder placement of st_ino in struct __stat64_t64

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 2916 bytes --]

Hi Joseph,

> On Wed, 14 Oct 2020, Lukasz Majewski wrote:
> 
> > This is required to make the minimal changes to provide
> > -D_TIME_SIZE=64 support for {f}stat{at} as in:
> > https://github.com/lmajewski/y2038_glibc/commit/26aa2ac07246682a505d85dac1c269689964b79b
> >  
> 
> Some basic principles for providing such support:
> 
> * struct stat and struct stat64 need updating simultaneously for all 
> architectures that currently use 32-bit times.  There are 11 
> bits/struct_stat.h headers under sysdeps/unix/sysv/linux/ (though
> some are for architectures with no 32-bit-time support); updating
> just one to handle _TIME_BITS=64 is not sufficient.

Ok.

> 
> * Since __stat64_t64 has the same layout across architectures, it's 
> strongly desirable to define its contents in only one place, rather
> than duplicating them in at least two copies in each of 11 headers.
> 
> This suggest some possibilities for complete but minimal changes:
> 
> * Define __STAT64_T64_CONTENT in some installed bits/ header and use
> it conditionally in each bits/struct_stat.h header.

I've poked around glibc code and I cannot find such paradigm - i.e.
defining as C preprocessor macro members of a struct in exported headers
files and then pasting it to internal and external headers.

Is it safe in the respect of using such approach in e.g. ld-*
program building?

As fair as I see - all core exported structures modifications use
members modification with #ifdef __USE_FOO and then solid type is added.

> 
> #if __GLIBC_USE (TIME_BITS64)
>   __STAT64_T64_CONTENT
> #else
>   /* existing struct contents */
> #endif
> 
> * Make bits/stat.h contain the conditional:
> 
> #if __TIMESIZE == 32 && __GLIBC_USE (TIME_BITS64)
> # include <bits/struct_stat_time64.h>
> #else
> # include <bits/struct_stat.h>
> #endif
> 
> (where bits/struct_stat_time64.h is a new installed header that
> defines both struct stat and struct stat64 with the __stat64_t64
> layout, maybe using a macro such as __STAT64_T64_CONTENT to avoid
> even duplication within the header).  I think this approach is more
> attractive because it avoids needing to make changes to lots of
> separate bits/struct_stat.h header.
> 

Wouldn't it be better to just make struct __stat64_t64 exported in e.g.
sysdeps/unix/sysv/linux/bits/struct_stat_time64.h and then just make
an alias in exported struct_stat.h
(sysdeps/unix/sysv/linux/bits/struct_stat.h):

#ifdef __USE_TIME_BITS64
#include <bits/struct_stat_time64.h>
#define stat __stat64_t64
#else
struct stat {
...
}
#endif

(the same approach for exported struct stat64).

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]