✘64-bit time_t on glibc 2.34 and up

[Gary E. Miller]

Yo Hal!

On Sat, 14 Jan 2023 08:30:08 -0800
Hal Murray <halmurray at sonic.net> wrote:

> Does this problem go away (for another 68 years) if on 32 bit systems,
>    we change the time_t in SHM to uint32_t?

No.  Some ILP32 already moved to int64_t for time_t.  Like all the BSDs.

> The SHM layout stays the same so all combinations of old/new will
> continue to work today.

No.  Some ILP32 already moved to int64_t for time_t.

> When the top bit turns on in 2038, recent builds will fill with 0s
> rather than sign extend when converting to a 64 bit time_t which is
> what we want.

And breaking a lot of existing stuff.  BSD's like to break stuff, but
not Linux.

> Old code using SHM and 32 bit time_t will do whatever in 2038.  I
> hope any interesting code will be recompiled by then.

Did you see the FAA NOTAM system that broke is running on Solaaris?
Care to guess the last update to that system?

> (Will we still
> be running Intel instruction sets?  ARM?)    If there is enough code
> that hasn't been updated, it wouldn't surprise me if somebody added a
> hack that said something like dates older than 1950 are really next
> era sp add 0x100000000 seconds when converting to text.

I'm still running and "maintaining" Pentiums from the '90s that have not
updated is a long time.

> There is a potential problem.  If a 32 bit OS/Distro has already
> converted to 64 bit time_t then we will break things if we convert to
> uint32_t.  So the decision to switch from time_t to uint32_t is more
> complicated that are we running on a 32 bit system.

I already pushed to gpsd git head a soltution that works in all cases.
And breaks nothing.  Unless you have a solution that breaks nothing, and
improves something, we are already done.

> How many 32 bit OSes do we run on?

Your guess ignores a lot of OS that gpsd runs on.  But off topic.  The
CPU arch is not relavant.  Only the size of time_t is.  And if a system
supports 2 sizes of time_t at the same time.

> In case nobody noticed, I hacked a sizeof(time_t) into NTPsec's
> configuration stuff a while ago.  So you can get the answer by
> looking in a handy config.h

Not good enough.  You need to set these for ILP32 glibc 2.34 and up:

    #define _TIME_BITS 64
    #define _FILE_OFFSET_BITS 64

See the gpsd issue for more details that you missed:

    https://gitlab.com/gpsd/gpsd/-/issues/152

As far as I am concerned, the gpsd side of this is done.
Nothing existing is broken (more), everything works going forward.
Nothing to improve (?).

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/20230114/1d5f7589/attachment.bin>