[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ✘64-bit time_t on glibc 2.34 and up
Re: ✘64-bit time_t on glibc 2.34 and up
Fri, 13 Jan 2023 13:43:06 -0600
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 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 as always 0 and dummy as a magic.
Then the reader looks at the structure in 32-bit time_t layout. If you
find dummy == magic && dummy == 0, then it is the 32-bit time_t
structure indeed. Else if dummy == magic && dummy == 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.
clockTimeStampSec clockTimeStampSec (first 32 bits)
clockTimeStampUSec clockTimeStampSec (second 32 bits)
receiveTimeStampUSec receiveTimeStampSec (first 32 bits)
leap receiveTimeStampSec (second 32 bits)
dummy ZERO dummy
dummy MAGIC dummy ZERO
dummy dummy 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
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.
Description: OpenPGP digital signature
My ignorance was Re: ✘64-bit time_t on glibc 2.34 and up, James Browning, 2023/01/13
Re: ✘64-bit time_t on glibc 2.34 and up,
Richard Laager <=
Message not available
Re: ✘64-bit time_t on glibc 2.34 and up, Hal Murray, 2023/01/13
- Re: ✘64-bit time_t on glibc 2.34 and up, (continued)
- Re: ✘64-bit time_t on glibc 2.34 and up, Gary E. Miller, 2023/01/13
- Re: ✘64-bit time_t on glibc 2.34 and up, Greg Troxel, 2023/01/14
- Re: ✘64-bit time_t on glibc 2.34 and up, Gary E. Miller, 2023/01/14
- Re: ✘64-bit time_t on glibc 2.34 and up, Greg Troxel, 2023/01/15
- Re: ✘64-bit time_t on glibc 2.34 and up, Gary E. Miller, 2023/01/15