Re: [Hamlib-developer] Year 2038 issues

[Black M. <mdb...@ya...>]

I think the best we can do is spit out a compiler error when trying to compile Hamlib and _TIMESIZE == 32.
Could make it a warning for now but that will just fly by and likely nobody will notice.

Down the road we can make it an error.

Mike W9MDB






On Friday, January 19, 2024 at 03:46:39 PM CST, Nate Bargmann <n0...@n0...> wrote: 





* On 2024 19 Jan 14:03 -0600, gm3zza via Hamlib-developer wrote:
> 
> 
> On 19 January 2024, at 18:53, van Wüllen <van...@Ch...> wrote:
> 
> >What is the problem? On my system (Mac OS), sizeof(time_t) is 8, that is,
> >time_t is a 64-bit integer.
> >I guess in 14 years there will be no system around with
> >time_t being 32 bit.
> 
> That complacency is the problem. 

Exactly.

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


> 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

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

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819


_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer