Re: ✘64-bit time_t on glibc 2.34 and up

[Greg Troxel]

"Gary E. Miller" <gem@rellim.com> writes:

>> Does Linux version syscalls?  In NetBSD, we change the codepoints when
>> the ABI changes, and there is kernel code to implement the old
>> codepoint (but no header support) so old binaries still work.  I
>> think Solaris does this too.
>
> For some definition of "version".  There is one set of syscalls for
> 32-bit time, including time in file system metadata.  And another
> for 64 bit time.  And only since late 2021.
>
>> I don't really follow "compile time option".  The size of time_t is
>> part of the kernel ABI.
>
> Yes.  BOTH sizes of time_t are part of the 32-bit linux kernel ABI.

Wow.  So people have to, specially for Linux, version all interfaces
that use time_t.  That's not just gpsd, but all sorts of things.

>> Or does the kernel use sys/types.h?
>
> Not relevant.

But it has codepoints for syscalls with each flavor.

>> The headers in sys are semantically part of the kernel, regardless of
>> how they are sliced up in packaging/maintenance.
>
> Sort of.  sys/tyoes.h is part of musl or glibc.

Yes, but it has to match the kernel.  That's why I said semantically
part of.

>> shmTime is simply using time_t, so it inherits the definition of
>> time_t from the compilation environment.  POSIX says that
>> <sys/time.h> is required to define time_t:
>> 
>>   https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_time.h.html
>
> Yes.  And it does.  Selected by  D_TIME_BITS 64

Which magically changes references to syscalls that use time_t, in the
entire binary, to the new ones?

What happens if a library defines D_TIME_BITS 64 and makes syscalls, and
a program which is unaware of this defines 32 and also makes sycalls?
Or is the syscall switch per .o because the names are #defined?

>> > 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 compatibility?  
>> 
>> It builds against the installed headers and just uses time_t.
>
> Yes, but which one?  The 32-bit one, or the 64-bit one?

I see.  Well, I see several sane paths:

  Make a new api in json to work around the Linux approach.  Only use it
  on Linux, with it just serializing the struct.  I really don't like this.

  The entire time community agrees that code will be built 64 if that's
  supported on the build system.  But then the "linux is one ABI" is
  falling apart and it's going to be a mess as there will be old code.
  So you have a rule that gpsd/ntpd/chronyd need to all be new or all be old.
  
  On Linux, redefine the struct to be int64_t instead of time_t.  add
  options to gpsd/ntpd/chrony to move to the new way.  After a bit take
  out the option and int64_t is the answer.  After time_t is int64_t on
  all linux systems rename it back to time_t.


I think the third option is the way to go.  That way each program can
use 32/64 as it is available but start using the new ABI now.  It will
interop and as each program is built for 64 it becomes 2038-safe.