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

[Richard Laager]

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

There might be an option to do something around 
leap/precision/nsamples/valid if some of those have sufficiently 
restrictive legal values. I'm not immediately seeing something obvious. 
The closest I see might be something around valid vs precision. If 
valid, for example, is 0 or 1 (with only 1 being useful) and 1 is not a 
valid precision, then you'd be able to differentiate them heuristically. 
That is, look at it as a 32-bit time_t struct; if valid is 1, then it's 
a valid 32-bit struct. If valid is 0, then you aren't going to use it 
anyway. If valid is anything else, then it's actually a 64-bit time_t 
struct (and you were looking at precision).

Do you know if, _in practice_, providers of shmTime are providing zeros 
for the dummy[8] padding? 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). One possible solution would be to burn a second integer of the 
padding and define e.g. dummy[3] as always 0 and dummy[5] as a magic. 
Then the reader looks at the structure in 32-bit time_t layout. If you 
find dummy[5] == magic && dummy[3] == 0, then it is the 32-bit time_t 
structure indeed. Else if dummy[7] == magic && dummy[3] == 0, then it is 
the 64-bit time_t structure. If neither of those match, then it is 
someone using the old-style no-magic structure and I suppose you have to 
assume the width of time_t is the same as what you were compiled with.

mode                  mode
count                 count
clockTimeStampSec     clockTimeStampSec (first 32 bits)
clockTimeStampUSec    clockTimeStampSec (second 32 bits)
receiveTimeStampSec   clockTimeStampUSec
receiveTimeStampUSec  receiveTimeStampSec (first 32 bits)
leap                  receiveTimeStampSec (second 32 bits)
precision             receiveTimeStampUSec
nsamples              leap
valid                 precision
clockTimeStampNSec    nsamples
receiveTimeStampNSec  valid
dummy[0]              clockTimeStampNSec
dummy[1]              receiveTimeStampNSec
dummy[2]              dummy[0]
dummy[3] ZERO         dummy[1]
dummy[4]              dummy[2]
dummy[5] MAGIC        dummy[3] ZERO
dummy[6]              dummy[4]
dummy[7]              dummy[5] MAGIC
                      dummy[6]
                      dummy[7]

> Options (for 32-bit only):
>
> 1.  Do nothing, stick with 32-bit time_t. Fail in 2038.

If we can easily do better, we should.

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

[reordered for reply flow]
>  3.  Add run time options to gpsd and ntpd to specify time_t size.

If we can't detect automatically, it seems like this is part of the 
solution.

So maybe this looks like:

- Use 64-bit time_t (generally, at compile time, for the whole
  application) if the platform supports it.

- For the SHM interface, default to using platform time_t size as now.

- Provide a run time option to force the SHM size to 32 or 64 bits.
  - This option should take effect on 32-bit architectures only.
    For config file compatibility, it should be parsed the same
    everywhere.  But then, on a 64-bit architecture, is specifying 32
    bit time_t for SHM an error, or ignored with a log warning?

The run-time configuration approach does not require any automatic 
detection or coordinating across multiple projects. It is both forwards 
and backwards compatible, but only by administrator action. The downside 
is requiring that administrator action, but that only happens in the 
case of mismatched time_t across the SHM boundary.

--
Richard

OpenPGP_signature
Description: OpenPGP digital signature