✘64-bit time_t on glibc 2.34 and up

[Gary E. Miller]

Yo Greg!

On Fri, 13 Jan 2023 20:20:48 -0500
Greg Troxel <gdt at lexort.com> wrote:

> Greg Troxel <gdt at lexort.com> writes:
> 
> I just had a realization.   What Linux is doing is more or less:
> 
>   Do the same thing that BSDs did: change time_t to in64_t and change
>   the syscall codepoints.  (Except you have to define something.)

No, not change time_t.  Add an incompatible alias to time_t.
 
>   Unlike the BSD approach, also support -- even on post-change systems
>   -- compiling code that uses int for time_t, and using the old
>   codepoints.

Uh, lost me?  I thought BSD had a flag day and just changed all
time_t to int64_t and broke all back compat?

> We could just treat the Linux approach like the BSD one and try ignore
> the ability to compile in "time_t is int" mode.

Sadly, Linux did not do that.  I doubt they twill change course now.


>  If all of
> gpsd/chronyd/ntpsec:
> 
>   By default (on Linux only) check if the flag to get "time_t is
>   int64_t" is available and use it

Which means old and new can't mix.  Not an option.

>   Have, for now, a --without to say "don't look for and use the define
>   to make time_t is int64_t".

No need with my proposed shmTime idea.

>   Each distribution/packaging system uses the without until all
> programs have an update with the above, and then flips them all off
> at once.

Yeah, which is why we still don't have puthon 3, openssl 3, or IPv6.

Bad idea.  My shmTime idea is forward and backward compatible.  No
flag day, not rebuild the world day.

> We do know all this code works fine when
> built in a "time_t is int64_t" environemnt from the last 9 years of
> use on NetBSD.

NetBSD just blew off binary compatibility.  Linux does not do that.

> then way, we end up just using the time_t is int64_t, with no options
> and no grossness, after some number of years.

Everything is so simple in BSD land, where you can tell your users
to do as you say.

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/ba2b73ff/attachment.bin>