Re: Can't Avoid That Shit Rust - Even On Gentoo

On 9/30/24 3:40 PM, candycanearter07 wrote:

186282@ud0s4.net <186283@ud0s4.net> wrote at 07:43 this Monday (GMT):

On 9/30/24 3:21 AM, rbowman wrote:

On Mon, 30 Sep 2024 06:03:29 -0000 (UTC), Lawrence D'Oliveiro wrote:
>

Fun fact: I was reworking an old perpetual-calendar program I first
wrote back in 1980, to use Fortran 90, a few months ago. And I found a
bug in my algorithm that never showed up in any years from the 20th
century, but did manifest itself in the 21st century.

>
Y2K rides again...  I think in many cases the problem was recognized in
the '70s and '80s but nobody expected the code to last decades.

>
    Very true - and TROUBLESOME.
>
    We all think in the NOW. With effort we can think
    a FEW years ahead. But a whole new century or
    something similar ... TOO MUCH WORK to future-
    proof. We'll "get back to it", sometime ......

  Then, people ignore the problem until it's right there.
For instance, the 2038 problem I'm betting will be ignored until 2035.

   Yep, for SURE.
   Human nature.
   Alas the PROBLEM tends to be several times larger
   than people THINK it will be, so ......
   Oh sure, just make time() into a proper 64-bit
   number ... but SO much downstream from that will
   NOT be prepared to deal with the 64 bit value.
   Basically EVERY subroutine that uses/manipulates
   time are still set up assuming unsigned 32-bit
   vars. This means MASS quantities of software that
   has to be re-written/re-compiled (at the last
   minute). Can't see ANY easy universal fix. Your
   assumptions chart your future.
   Yea, they can write a time64(), but everything
   still has to re-done.
   I may live until 2038, so this WILL be a huge
   problem. Can I even get my pension/govt
   payments ??? Insurance ??? Probably won't be
   in shape to physically travel to offices of
   all these entities.
   Again, way back, 2038 seemed SO far away ...
   don't worry about it ..........