- xkcd: Y2K and 2038 - 11 Updates
- Simulating halt decider applied to a simpler input - 3 Updates
| Thomas Koenig <tkoenig@netcologne.de>: Nov 12 07:36AM > xkcd: Y2K and 2038 > https://xkcd.com/2697/ > It shouldn't cost more than a trillion dollars or two to investigate this. The switchover to 64-bit systems should have done this. Not sure that this cost a trillion dollars, but computers usually have a limited lifetime, so they had to be replaced anyway. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Nov 12 01:58AM -0600 On 11/12/2022 1:36 AM, Thomas Koenig wrote: > The switchover to 64-bit systems should have done this. Not sure > that this cost a trillion dollars, but computers usually have a > limited lifetime, so they had to be replaced anyway. Most software is still 32 bit. Having the operating system as 64 bit helps but it does not solve the problem of the 32 bit software running on it. An unsigned 32 bit integer only gets us to 2106. https://en.wikipedia.org/wiki/Year_2038_problem Porting software to 64 bit is a tremendous work for most software. Lynn |
| Thomas Koenig <tkoenig@netcologne.de>: Nov 12 08:30AM > on it. An unsigned 32 bit integer only gets us to 2106. > https://en.wikipedia.org/wiki/Year_2038_problem > Porting software to 64 bit is a tremendous work for most software. UNIX went through that in the mid-nineties to mid-noughties. It mostly involved cleaning some assumptions about pointer vs. int size. Clean code was OK from the start, but to lessen the pain, most operating systems adopted I4LP8 (integers four bytes, longs and pointers eight bytes). The important thing was that the interfaces remained constant at the API level. I believe what you're discribing is not 32 vs. 64 bit in general, but rather a peculiarity of Windows which Microsoft inflicted on its customers because, well, they could. |
| Muttley@dastardlyhq.com: Nov 12 10:00AM On Sat, 12 Nov 2022 01:58:44 -0600 >Most software is still 32 bit. Having the operating system as 64 bit >helps but it does not solve the problem of the 32 bit software running >on it. An unsigned 32 bit integer only gets us to 2106. I suspect that'll be long enough. The sorts of computers running in 80 years time will probably bear little resemblence to what we have now. > https://en.wikipedia.org/wiki/Year_2038_problem >Porting software to 64 bit is a tremendous work for most software. Not really as long as the programmer hasn't done something stupid like assuming the size of int or long instead of using int32_t etc. |
| David Brown <david.brown@hesbynett.no>: Nov 12 11:29AM +0100 On 12/11/2022 08:58, Lynn McGuire wrote: > on it. An unsigned 32 bit integer only gets us to 2106. > https://en.wikipedia.org/wiki/Year_2038_problem > Porting software to 64 bit is a tremendous work for most software. Most *nix software has been 64-bit clean for decades. Most /new/ Windows software is 64-bit clean. A fair bit of modern software on Windows is cross-platform, sometimes originating in the *nix world, and that will be fine with 64-bit. The only PC software that has trouble with 64-bit is Windows software with a long history, and written with poor code. Code that assumes pointers fit in longs, or that LONG is a suitable type for holding a time value, will have trouble. So yes, that kind of software will be a problem - and some of it will still be in use by 2038. There will be some local problems within company-specific software - but there are /always/ problems with company specific software as requirements change and assumptions are no longer valid. I don't foresee Y2038 being specially problematic. For embedded software, this will not be much of an issue. The great majority of embedded software doesn't have any need of dates or long timings. For small systems that /do/ need dates or long times, it's common to have your own formats to keep track - it's far smaller code to increment a second/minute/hour/day/month/year tracker every second, than to deal with the mess of leap seconds, locales, and other complications of converting UNIX epoch to local time. Also, good embedded developers take overflows into account all the time. They are more likely to see a 32-bit millisecond counter than a second counter, and that overflows after 49 days - it is something you understand and you make sure the code does not fail after 49 days. My only real concern about Y2038 is excessive paranoia and bureaucracy. I expect to be inundated with requirements to document that some flashing light we made in 1990 does not suffer from Y2038 problems. |
| Bart <bc@freeuk.com>: Nov 12 11:03AM On 12/11/2022 10:29, David Brown wrote: > Windows software is 64-bit clean. A fair bit of modern software on > Windows is cross-platform, sometimes originating in the *nix world, and > that will be fine with 64-bit. The size of C 'int' on the Windows and Linux systems I have encountered still seems to be stuck on 32 bits. Which means people lazily using that instead of `int64_t` etc, or using is as a "don't care" type, are continuing to perpetuate 32-bit-dominated software. > pointers fit in longs, or that LONG is a suitable type for holding a > time value, will have trouble. So yes, that kind of software will be a > problem - and some of it will still be in use by 2038. It is the 'long' type that is problematic. On Windows that is at least consistently 32 bits on Win32 and Win64 systems. If you assume it is the same size as `void*`, you will quickly discover it isn't on Win64. On Linux, I think it is 32 bits on Linux32 and 64 bits on Linux64, so any assumptions about it there will have more subtle consequences. |
| David Brown <david.brown@hesbynett.no>: Nov 12 12:57PM +0100 On 12/11/2022 12:03, Bart wrote: > Which means people lazily using that instead of `int64_t` etc, or using > is as a "don't care" type, are continuing to perpetuate 32-bit-dominated > software. There's nothing wrong with using 32-bit types. The problem only comes when you use a 32-bit type for something that might not fit in 32 bits. So if there are people using "int" for "time_t", pointers, or other things that are unsuitable, then that's a problem. Otherwise, it's fine to use 32-bit types for 32-bit values. It is often /better/, because it makes better use of cache (obviously this matters most for arrays) and memory bus bandwidth, it can be faster for some operations, and allows more use of SIMD operations. > It is the 'long' type that is problematic. On Windows that is at least > consistently 32 bits on Win32 and Win64 systems. If you assume it is the > same size as `void*`, you will quickly discover it isn't on Win64. Windows programmers were used to assuming that "long" meant "32-bit", and that "long" was the same size as pointers. MS could only make one of these assumptions remain when they moved to 64-bit - they picked the wrong one. (It was especially wrong given that their C compiler didn't support C99 and "long long int" at the time, and had no proper 64-bit integer type!) > On Linux, I think it is 32 bits on Linux32 and 64 bits on Linux64, so > any assumptions about it there will have more subtle consequences. In the *nix world, programmers have /long/ been used to avoiding such assumptions. The idea of having everything as a single platform that never changes, so you can pretend the basic C types have particular fixed characteristics, or assume platform endianness, or strong memory models - that's all from the DOS/Windows world. You can't blame Linux for the problems MS caused by picking solutions that are different from everyone else, or caused by DOS/Windows programmers writing crap code for decades. |
| Paavo Helde <eesnimi@osa.pri.ee>: Nov 12 04:13PM +0200 12.11.2022 09:36 Thomas Koenig kirjutas: > The switchover to 64-bit systems should have done this. Not sure > that this cost a trillion dollars, but computers usually have a > limited lifetime, so they had to be replaced anyway. 64-bit system does not help if the program does not use it. At least boost xtime used to have 'long' counters, which indeed are 64-bit in some 64-bit implementations, but not so in others. Not sure about their current state, I have phased boost::xtime out in preparation for Y2038. |
| Bart <bc@freeuk.com>: Nov 12 03:56PM On 12/11/2022 11:57, David Brown wrote: >> using is as a "don't care" type, are continuing to perpetuate >> 32-bit-dominated software. > There's nothing wrong with using 32-bit types. I think there is. You would question code, running on a PC where 'int' was i32, that specifically used int16_t everywhere for parameters, return types, and individual global and local variables for no particular reason. Since it's not really going to save space. Outside of C, I would only use an i32 type for the same reason I might choose i16 or i8: to optimise storage and layout for arrays and structs, or as the target of a pointer into such a structure. Otherwise there is little point on a 64-bit system where registers and stack slots are 64 bits anyway. Especially as a 32-bit int is 4 billion times more likely to overflow. |
| scott@slp53.sl.home (Scott Lurndal): Nov 12 04:05PM >> that this cost a trillion dollars, but computers usually have a >> limited lifetime, so they had to be replaced anyway. >Most software is still 32 bit. In what year? That's certainly not the case today, and it will be even less so by 2038. And how much of that software uses time_t? |
| Michael S <already5chosen@yahoo.com>: Nov 12 10:05AM -0800 On Saturday, November 12, 2022 at 12:30:12 PM UTC+2, David Brown wrote: > pointers fit in longs, or that LONG is a suitable type for holding a > time value, will have trouble. So yes, that kind of software will be a > problem - and some of it will still be in use by 2038. Native 32-bit Windows software should have no problems, because native Windows time APIs never counted time as seconds starting form 1970. Only *nix programs that were ported to Win32 too literally can became problematic, but more likely not in 2038, but when all 32 bits wrap around in 2106. > My only real concern about Y2038 is excessive paranoia and bureaucracy. > I expect to be inundated with requirements to document that some > flashing light we made in 1990 does not suffer from Y2038 problems. Many people made money from paranoia of Y2K. They or their children are interested in doing it again. |
| olcott <none-ya@beez-waxes.com>: Nov 11 06:05PM -0600 On 11/11/2022 5:48 PM, Richard Damon wrote: > Right, and it does when CORRECTLY (and completely) simulated or directly > executed. > H just aborts its simulation too soon. *This is the part where you are either incompetent or a liar* Any expert in C knows that the correctly simulated E never reaches its own final state even if an infinite number of steps are correctly simulated. Thus H is correct to predict that its input never halts. void E(void (*x)()) { H(x, x); } int main() { H(E,E); } -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| olcott <polcott2@gmail.com>: Nov 12 08:43AM -0600 On 11/12/2022 8:02 AM, Richard Damon wrote: > shows the program is non-halting? > I will note that E(E) calling H(E,E) is NOT such a pattern, as E(E) will > halt if H(E,E) is defined to abort that simulation and return 0. void Infinite_Loop() { HERE: goto HERE; } It is an easily verified fact that Infinite_Loop correctly simulated by H would never reach its own last instruction and terminate normally after 1 to ∞ steps of correct simulation. void E(void (*x)()) { H(x, x); } It is an easily verified fact that E correctly simulated by H would never reach its own last instruction and terminate normally after 1 to ∞ steps of correct simulation. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| olcott <polcott2@gmail.com>: Nov 12 09:50AM -0600 On 11/12/2022 9:03 AM, Mr Flibble wrote: > all the way down: a manifestation of the category error I have > identified. > /Flibble void E(void (*x)()) { H(x, x); } The point is that D correctly simulated by H would never reach its own last instruction and terminate normally after 1 to ∞ steps of correct simulation. When H returns 0 to main() it is indicating that D correctly simulated by H would never reach its own last instruction and terminate normally after 1 to ∞ steps of correct simulation. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment