✘64-bit time_t on glibc 2.34 and up

[Gary E. Miller]

Yo Greg!

On Sat, 14 Jan 2023 09:26:45 -0500
Greg Troxel <gdt at lexort.com> wrote:

> >>   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.  
> 
> When you compile with -D _TIME_SIZE_BITS=64, doesn't it cause time_t
> to be a different type for that compilation?

Yes,  This is discussed in the issue:

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

#ifdef __USE_TIME_BITS64
typedef __time64_t time_t;
#else
typedef __time_t time_t;
#endif


> 
> >>   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?  
> 
> Not quite.
> 
>   time_t was changed to int64_t
> 
>   all syscalls that have time_t in the ABI got a new number
> 
>   compat syscalls were added that use the old ABI, using the old
>   numbers.
> 
> Thus:
> 
>   newly built programs see time_t as int64_t and use the new syscalls
> 
>   binaries from Before, which have code to use time_t as 32 bits, use
>   the compat syscalls and thus continue to work (until 2038).  For
>   example you can boot a NetBSD 6 kernel on a system with 5 userland
> and packages built under 5 and it all works fine.
> 
>   nothing was done about ABIs like the gpsd/ntpd/chrony ones.  So you
>   need all of those programs consistently from before or after.
> 
>   Aside from programs that have these inter-program ABI with time_t,
>   everything is ok, even with a mix of old and new binaries.

Uh, no.  You can not mix SHM used by programs built before and after
the switch.  Beacuse the size and layout differes.

Thus, a flag day, thus breakage.

> > Sadly, Linux did not do that.  I doubt they twill change course
> > now.  
> 
> But we can choose to always define _TIME_SIZE_BITS=64 when building on
> Linux.  That's what I meant by ignore the ability to compile in the
> old way: just don't.

And thus break all existing binaries.  Nope, not gonna happen.  BSD
hates its users, not Linux.

> >>  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.  
> 
> I think it's a perfectly reasonable option.  Packaging systems
> (distributions) are going to have to deal with this in general.

Like they have with python 2.7, openssl 3. ffmpeg?  No, this is not
a solved problem.  Don't pretend it is.

> > NetBSD just blew off binary compatibility.  Linux does not do that.
> >  
> 
> Not at all, see above.

Wrong, see above.

> Binary compat is excellent in this case.

Except the case we care about SHM and chrony socket.

> > Everything is so simple in BSD land, where you can tell your users
> > to do as you say.  
> 
> That's unfair, and this discussion has crossed into no longer useful.

I agree.  The change is already made.

> I have no memory of pain from the transition.

Short memory.

> People basically
> upgraded packages from ones built for 5 to ones built for 6, just as
> they typically do when upgrading and went from all old to all new,

Sadly Gentoo, and some other Linux do not have versions.  And even the
ones that do still are trying to handle python 2.7, openssl 3, ffmpeg,
etc.

> The problem here is because various distributions will change to the
> new kernel at various times but there is an idea that there is a
> single Linux ABI.


Corrext.  Things change randomly, and there is no single Linux ABI.
That is my world, I'm stuck with it.

> Still, if the syscalls that programs see when
> building with _TIME_SIZE_BITS=64 have new codepoints:
> 
>   old and new binaries should run on new kernels
> 
>   only old binaries will run on old kernels
> 
>   programs with non-syscall ABIs with time_t need to either
> 
>     be consistently old or new
> 
>     do something kludgy

Which totally ignores the problem at hand: the size of SHM and chronyd
structs.

> I don't see it as a problem to expect 3 programs to be all old or all
> new.

For you, in BSD land, but for us in the real world...

> But as long as the accomodations for this are all #idef linux, I don't
> really care.

Amazing enough, not required.  And already done.

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/4679f186/attachment-0001.bin>