Re: [Hamlib-developer] Year 2038 issues

[Greg T. <gd...@le...>]

Nate Bargmann <n0...@n0...> writes:

> It's not out of the realm of possibility that I'll still have some 32
> bit hardware laying around 14 years from now.  I doubt any of it will be
> used to run Hamlib and on the only system I use Hamlib on I've been
> running 64 bit Linux for years but that doesn't necessarily mitigate the
> issue as I understand it (not well).

This is not about systems with CPUs with 32-bit native word sizes.  It
is about operating systems that choose a 32-bit type for time_t.

>> Is there a defined 64bit time type in C? Hamlib is C isn't it? 
>
> I believe that glibc does have a 64 bit time_t, but my
> (mis)understanding is that time_t is limited to 32 bits.  Perhaps this
> link is helpful:
>
> https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html

Wow, it's "LFS" all over again, instead of just changing the types to be
big enough and versioning the binary syscalls.

I think it would be a net minus to ick up the code to accomodate this,
but maybe it can be done with a block of #defines that is gated on if it
is glibc.  That says "not actually implemented", so it seems unwise to
put effort into it until the support becomes real.

> I am not sure what other C libraries are doing for mitigation.

This is an OS bug and should be fixed there, and if not, oh well.  The
BSD world fixed it long ago.  The Linux approach seems to be that 64-bit
CPUs have a reasonable time_t size, and 32-bit CPUs do not.  That is,
whether they would see it that way or not, a decision by Linux that
32-bit CPU systems may not be used close to/after 2038.  I say don't
tilt at this windmill at all; it's not about hamlib and many other
things are going to break.

I think that 32-bit computers running Unix are going to be extremely
rare by 2038 and even 2033, in other than a retrocomputing for fun kind
of way.  I tend to have old computers because I keep things that work
and accept free-to-good-home for random testing use.  I am running
NetBSD in i386 mode on a few systems which would accept amd64 (but
time_t is fine).  And in earmv7hf-el (32) mode on 2 systems that would
accept evbarm64-el (64) mode.  I'm doing this not for any good reason,
other than that some systems were installed long ago (18 years in one
case), and I haven't seen a reason to switch to amd64/aarch64, since
with limited memory (1-2GB) it doesn't really help anything.

The only (unix-capable) hardware I have that wouldn't run in a 64-bit
cpu mode is:

   one RPI1
   soekris net5501

Today, neither is in use.  I might try to use the RPI1 soon.  But I
can't imagine wanting to use or keep using either after January, 2034.
That's not really about 32-bit CPU so much as limited RAM (512 MB in
each case) and slow.  Already today, running a system with that little
RAM is a recipe for grief.  I bet that by then people will be saying to
me "I'm going to recycle some RPI3s - do you want them?".

Do we really expect people to be using 32-bit-only hardware (really
using, not proving that there is a problem) after 2033?

How many people are using it *today*, with hamlib?  Is there anyone?  If
so, why and what is the path between now and 2033?