pyotr filipivich <ph...@mindspring.com
>sc...@slp53.sl.home (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44 GMT
>typed in rec.arts.sf.written the following:
>>Ninapenda Jibini <taus...@gmail.com
>>>sc...@slp53.sl.home (Scott Lurndal) wrote in
>>>> For the most part, a nothingburger. However, there are likely
>>>> lots of small embedded 32-bit processors in devices like routers
>>>> which may exhibit issues, if they're still running 16 years from
>>>You sound just like the doom criers ("Give me money or you'll
>>>DIE!!!") in the run up to y2k.
>>I said "if they're still running 16 years from now", which is
>>quite unlikely. However, cheap-ass manufacturers may continue
>>to use the same software in newer devices, sadly.
> It is possible. As the cliche was "back in my day" - most of the
>current batch of programmers have no idea that there are COBOL
>programs still running which were compiled before they were born.
> The question is, how many people / organizations have a system
>which has been running, is running, will be running, with little or no
>reason to replace it with a New And Improved Hardware?
Most of those workloads are still running on legacy iron, and will
for the forseeable future (IBM, Unisys). Modern workloads based on
current distributed technologies (the world-wide web, for instance)
are either already 64-bit clean. The time_t issue is uniquely an
Unix issue and those, aside from the low-end consumer grade hardware mentioned
above, are largely already 64-bit clean.
The competence of programmers varies, and it is likely that there is
a fair amount of software that treats time_t as interchangable with
the C/C++ 'int' type, which is prima facia broken, but works in 32-bit
environments (and may continue to work post 2038 depending on the
context of the usage).