[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ✘64-bit time_t on glibc 2.34 and up

From: Gary E. Miller
Subject: Re: ✘64-bit time_t on glibc 2.34 and up
Date: Fri, 13 Jan 2023 12:32:22 -0800

Yo Richard!

On Fri, 13 Jan 2023 13:43:06 -0600
Richard Laager <> wrote:

> On 1/12/23 19:10, Gary E. Miller via devel wrote:
> > How does ntpd know what size time_t to use? And thus know the size
> > of shmTime?  How do we know portably, preserving backwards and
> > forwards compatibility?
> > 
> > In hindsight, maybe shmTime should have started with a 1 char
> > version field,or magic field.  But, no such luck.  
> Here are some thoughts on various options.
> I don't know what valid values of "mode" are.

I snipped that part from include/timehint.h:

    int mode;   /* 0 - if valid set
                 *       use values,
                 *       clear valid
                 * 1 - if valid set
                 *       if count before and after read of values is equal,
                 *         use values
                 *       clear valid

Clear as mud...

Looks like gpsd only ever sets it to a 1.

NTPsec ntpd/refclock_shm.c (un)helpfully says:

 * To add new modes: Extend or union the shmTime-struct. Do not
 * extend/shrink size, because otherwise existing implementations
 * will specify wrong size of shared memory-segment

Maybe set mode = 2, and use two of the dummy from shmTime:

        int             dummy[8];

> Could that be used, 
> possibly by setting some high bit(s) to indicate a 64-bit time_t and
> a 32-bit int? That would break backwards compatibility, though, as
> old readers would see modes they do not expect.

NTPsec would reject a mode of 2:

                shm_stat->status = BAD_MODE;

Maybe keep mode of 1, and dummy[0] could be the top bits of time64_t?

Then old and new clients work until 2038.  And new clients after that.

> Do you know if, _in practice_, providers of shmTime are providing
> zeros for the dummy[8] padding?

All I care about is gpsd, and it does zero the padding.  Once.

 If so, then (subject to agreement
> from the various projects), part of that could be defined as a magic.
> Of course, the problem there is that you need to find dummy[x], which
> can be in different positions depending on the struct size (which is
> the issue at hand).

That is fixable.  Just force the existing time_t to be time32_t on
32-bit systems that support 2 types of time_t.  The other fields are
"int" and "unsigned".

> One possible solution would be 

Too complicated.  If dumm[0] is non-zero, take that as the top 32
bits of time64_t.  But only on 32-bit dual time_t systems.

Along the way, pull the duplicate shmTime definitions from NTPsec
and gpsd and put them in one system header file.

> > 4.  gpsd and ntpd always use 64-bit time_t going forward.  Admin
> > needs to mix and match.  
> I think ntpd (and probably gpsd too) should enable whatever option to 
> use 64-bit time_t if the platform supports it. But do we need to
> still support existing 32-bit platforms where time_t is only 32-bit?
> Probably?

Certainly.  At least until 2038.

chrony sockets are still a problem...

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpWHtCt_6YxF.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]