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

[Lukasz Majewski <lukma at denx dot de>]

Hi Paul, Joseph,

Thank you for your feedback.

> On 3/28/19 10:25 AM, Joseph Myers wrote:
> >
> > I don't think we should be particularly concerned by what __* names
> > are visible to user code; the visibility of such names is simply a
> > side-effect of how the C language works.  
> 
> Hmm, well, our opinions differ, as I've seen too many people abusing
> the C-language rules and would rather avoid these problems when it's
> easy, as it is here.
> 
> However, as long as __time64_t and __time_t are not visible to user
> code when _TIME_BITS=64, this will address most of my own practical
> concerns and should be OK as a compromise.

To sum up:
----------

1. __time64_t and __time_t are "exported" (visible in /usr/include/*)
always (similar to __off_t and __off64_t).

2. The "exported" struct timespec would look like:

struct timespec
{
/* Use the original definition for 64-bit arches
   or when 64-bit-time by default has *not* been requested */
#if __WORDSIZE > 32 || ! defined(__USE_TIME_BITS64)
  __time_t tv_sec; /* Seconds. */
#else
  __time64_t tv_sec;
#end
  __syscall_slong_t tv_nsec;
};

The same code would be use with e.g. struct timeval

3. Put the internal struct __timespec64

struct __timespec64
{
  __time64_t tv_sec;
  __int64_t tv_nsec;
}

into include/time.h and don't introduce separate
include/bits/types/struct___timespec64.h 

The same idea would be applied to struct timeval

4. Syscalls conversion - starting with Linux only - performed as
described in: "D.2.1 64-bit time symbol handling in the GNU C Library"
https://www.gnu.org/software/libc/manual/html_mono/libc.html

(As done with clock_settime() in this RFC patch set).

5. Add some glibc tests (which could be also easily adapted to test
after Y2038 scenario) after converting some calls (like e.g.
clock_{settime|gettime|nanosleep|getres,etc}).

> 
> > They should be present, or not, however is 
> > convenient for implementing and maintaining the installed headers
> > (which includes keeping those headers consistent between different
> > *_t typedefs in most cases).  
> My impression is that it will be more convenient to put __time64_t in
> a private header, to help remind maintainers that that the situation
> with time_t is different, as there is no intent to support mixed-mode
> user code with time_t. But I understand if your opinion differs.
> 




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