[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: Richard Laager
Subject: Re: ✘64-bit time_t on glibc 2.34 and up
Date: Fri, 13 Jan 2023 13:43:06 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

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

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

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.


Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

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