Re: [RFC 1/7] y2038: Introduce struct __timespec64

[Lukasz Majewski <lukma at denx dot de>]

Hi Joseph,

> On Wed, 27 Mar 2019, Lukasz Majewski wrote:
> 
> > User space programs on 32 bit machines use struct timespec, which
> > when one passes -D_TIME_BITS==64 -D_FILE_OFFSET_BITS==64 during
> > compilation is replaced by struct __timespec64, which correctly
> > handles time after Y2038.
> > Then glibc functions work on struct __timespec64 and provide
> > results to user space program.  
> 
> By comparison, for _FILE_OFFSET_BITS=64 the headers e.g. continue to 
> define "struct stat", but with different contents in that case.  So
> it would be possible to do the same with "struct timespec" rather
> than defining it to __timespec64.

Ok. I've looked into the ./bits/stat.h source code:

#ifndef __USE_FILE_OFFSET64
    __ino_t st_ino;             /* File serial number.  */
#else
    __ino64_t st_ino;           /* File serial number.  */
#endif

In this case explicit 64 bit type is used (__ino64_t).

On important information from the above - it is allowed to use
__USE_FILE_OFFSET64 (which corresponds to __USE_TIME_BITS64 for time).

> 
> There are arguments either way (e.g. defining timespec to
> __timespec64 results in different C++ name mangling when
> _TIME_BITS=64 is used, which may be a good idea).  But given the
> question recently raised about whether __time64_t belongs in the
> installed headers, there needs to be a careful justification given
> for the particular approach chosen, whichever approach it ends up
> being.
> 

I will state more details about this problem in the other mail - one
related to Paul's mktime rework (and hiding __time64_t to be only
glibc/gnulib private type).


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: pgpWHW4qBrsoM.pgp
Description: OpenPGP digital signature