▲ 138 ▼ The Epochalypse: It’s Y2K, But 38 Years Later (hackaday.com) submitted 1 year ago by mesamunefire@piefed.social to c/technology@lemmy.world 27 comments fedilink hide all child comments
[–] ramble81@lemmy.zip 18 points 1 year ago (5 children) Not really. 32-bit apps can use 64-bit values. permalink fedilink source parent hideshow 5 child comments replies: [–] IllNess@infosec.pub 6 points 1 year ago (4 children) So this is only a problem for 32-bit apps on 32-bit processors? permalink fedilink source parent hideshow 4 child comments replies: [–] InnerScientist@lemmy.world 21 points 1 year ago No, those can have 64 bit value as well, this is only a problem for applications which haven't switched to using them. permalink fedilink source parent [–] nyan@lemmy.cafe 8 points 1 year ago (1 child) 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. permalink fedilink source parent hideshow 1 child comment replies: [–] jjlinux@lemmy.ml 3 points 1 year ago I don't think anyone's actually dumb enough to do that Never underestimate human stupidity. permalink fedilink source parent [–] sgh@lemmy.ml 7 points 1 year 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). permalink fedilink source parent
[–] IllNess@infosec.pub 6 points 1 year ago (4 children) So this is only a problem for 32-bit apps on 32-bit processors? permalink fedilink source parent hideshow 4 child comments replies: [–] InnerScientist@lemmy.world 21 points 1 year ago No, those can have 64 bit value as well, this is only a problem for applications which haven't switched to using them. permalink fedilink source parent [–] nyan@lemmy.cafe 8 points 1 year ago (1 child) 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. permalink fedilink source parent hideshow 1 child comment replies: [–] jjlinux@lemmy.ml 3 points 1 year ago I don't think anyone's actually dumb enough to do that Never underestimate human stupidity. permalink fedilink source parent [–] sgh@lemmy.ml 7 points 1 year 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). permalink fedilink source parent
[–] InnerScientist@lemmy.world 21 points 1 year ago No, those can have 64 bit value as well, this is only a problem for applications which haven't switched to using them. permalink fedilink source parent
[–] nyan@lemmy.cafe 8 points 1 year ago (1 child) 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. permalink fedilink source parent hideshow 1 child comment replies: [–] jjlinux@lemmy.ml 3 points 1 year ago I don't think anyone's actually dumb enough to do that Never underestimate human stupidity. permalink fedilink source parent
[–] jjlinux@lemmy.ml 3 points 1 year ago I don't think anyone's actually dumb enough to do that Never underestimate human stupidity. permalink fedilink source parent
[–] sgh@lemmy.ml 7 points 1 year 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). permalink fedilink source parent