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

[Greg Troxel]

Hal Murray <halmurray@sonic.net> writes:

> Does this problem go away (for another 68 years) if on 32 bit systems,
>    we change the time_t in SHM to uint32_t?
>
> The SHM layout stays the same so all combinations of old/new will continue to 
> work today.
>
> 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.
>
> Old code using SHM and 32 bit time_t will do whatever in 2038.  I hope any 
> interesting code will be recompiled by then.  (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 think the kernel of your idea is great, with two modifications.

First, the idea that "time_t is int32_t" on "32-bit systems" is not in
general true.  We have seen that some are "long" (which is int32_t) and
some are "int64_t".  This means:

  We can't change the type to a different size.

  If the OS straightforwardly defines a time_t that is big enough, it's
  not broken and we shouldn't mess with it.

> 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.

Indeed it is.

> How many 32 bit OSes do we run on?

That's not really the right question, because gpsd should operate on any
reasonable mostly-POSIX system, and we don't have a list.

> 32 bit Linux/Debian has 32 bit time_t on i686

sparc, powerpc, mips?

> 32 bit FreeBSD has 32 bit time_t on i386
> 32 bit FreeBSD has 64 bit time_t on armv7 and armv6

sparc, powerpc, mips?

> 32 bit NetBSD has 64 bit time_t on Intel and Pi 2

Actually all systems are int64_t regardless of CPU.

It looks like OpenBSD changed to int64_t in 2013.

I don't know about DragonFly or Solaris/illumos/etc.

But those answers aren't really relevant to the discussion.  We know
some have changed to int64_t and some have not, and that one system is
planning to support both at the same time.

1) On systems with big-enough time_t (int64_t in practice), nothing is
wrong and nothing should change.

2) On systems with small time_t (int32_t, "long" on i386, etc.), gpsd
isn't doing anything wrong and nothing should change in gpsd.  (These
systems should convert to type 1 or type 3, not our issue.)

3) On systems with a compile time choice of time_t or one where
culturally it is important to run arbitrary mixes of old and new
binaries, it's difficult.  These systems are exactly, I think:

  Linux, where time_t is now/recently equivalent to int32_t

The ntpshm ABI should on those systems be

  Instead of time_t, use uint32_t.  Store the truncated value of the
  right value of time_t.  On reading, disambiguate it into the current
  epoch.

which is no change until 2038, and the sign bit (no longer sign) as you
say.  This is similar to Gary's proposal to store the high 32 bits
someplace else, except a) not doing that and b) disambiguating on read.

So as long as this is limited to a specific set of OS-CPU tuples which
have the ability to have multiple time_t representations, I think it's
good enough.

I object to changing the ABI on systems that are not troubled or don't
have any int64_t time_t.  That's a pretty large set, basically
everything except Linux on amd64 and some other CPUs.

The problem is that there isn't a strategy to end up, after Linux
eventually changes to only int64_t, with an ABI that has time_t and
lacks the extra ick and complexity.  But it's 99% staying the course
until then.


Separately, what is FreeBSD planning to do about i386?  Deprecate it by
2030?  Right now it seems ppc, arm, mips are having more staying power.
i386 is fading as pre-x86-64 hardware is now really old, 2005 for normal
and 2012 for embedded (e.g. soekris net5501).  While I am operating 3
machines as i386, they are all capable of switching and will be recycled
anyway before 2038 -- they are all from 2006.  And I have only one
machine that is i386 only, a net5501 no longer in service.  So maybe
i386 doesn't matter and this is more about arm and riscv-32.