✘64-bit time_t on glibc 2.34 and up

[Gary E. Miller]

Yo Richard!

On Fri, 13 Jan 2023 13:43:06 -0600
Richard Laager <rlaager at wiktel.com> 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:

            default:
                shm_stat->status = BAD_MODE;
                break;

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...

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20230113/c66719c8/attachment.bin>