Comment on The Epochalypse: It’s Y2K, But 38 Years Later

MCasq_qsaCJ_234@lemmy.zip ⁨3⁩ ⁨days⁩ ago

• ramble81@lemmy.zip ⁨3⁩ ⁨days⁩ ago

  Not really. 32-bit apps can use 64-bit values.

  source

  • IllNess@infosec.pub ⁨3⁩ ⁨days⁩ ago

    So this is only a problem for 32-bit apps on 32-bit processors?

    source

    • InnerScientist@lemmy.world ⁨3⁩ ⁨days⁩ ago

      No, those can have 64 bit value as well, this is only a problem for applications which haven’t switched to using them.

      source
    • nyan@lemmy.cafe ⁨3⁩ ⁨days⁩ ago

      It’s a problem with the internal represensation of a C/C++ type alias called time_t, mostly. That’s the thing that holds the number of elapsed seconds since midnight on Jan. 1, 1970, which is the most common low-level representation of date and time on computers. In theory, time_t could point to a 32-bit type even on a 64-bit system, but I don’t think anyone’s actually dumb enough to do that. It affects more than C/C++ code because most programming languages end up calling C libraries once you go down enough levels.

      In other words, there’s no way you can tell whether a given application is affected or not unless you’re aware of the code details, regardless of the bitness of the program and the processor it’s running on.

      source

      • jjlinux@lemmy.ml ⁨3⁩ ⁨days⁩ ago

        I don’t think anyone’s actually dumb enough to do that

        Never underestimate human stupidity.

        source
    • sgh@lemmy.ml ⁨3⁩ ⁨days⁩ ago

      It only depends whether the app and its OS/kernel interface use a 32-bit value to store the time information.

      32-bit architecture or OS has nothing to do with this bug, for example 16-bit architectures must’ve used 32-bit time, too (otherwise they’d be able to only count up to 32-65 seconds).

      source