Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #168159

Re: xkcd: Y2K and 2038

Cross-posted to 2 groups.

Show all headers | View raw

On 12/11/2022 12:03, Bart wrote:
> On 12/11/2022 10:29, David Brown wrote:
>> On 12/11/2022 08:58, Lynn McGuire wrote:
>>> On 11/12/2022 1:36 AM, Thomas Koenig wrote:
>>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>>> 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.
>>>
>>> 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.
>>>
>>
>> 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 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.

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.

> 
>> 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.
> 
> 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.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

xkcd: Y2K and 2038 Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-11 14:29 -0600
  Re: xkcd: Y2K and 2038 Thomas Koenig <tkoenig@netcologne.de> - 2022-11-12 07:36 +0000
    Re: xkcd: Y2K and 2038 Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-12 01:58 -0600
      Re: xkcd: Y2K and 2038 Thomas Koenig <tkoenig@netcologne.de> - 2022-11-12 08:30 +0000
      Re: xkcd: Y2K and 2038 Muttley@dastardlyhq.com - 2022-11-12 10:00 +0000
      Re: xkcd: Y2K and 2038 David Brown <david.brown@hesbynett.no> - 2022-11-12 11:29 +0100
        Re: xkcd: Y2K and 2038 Bart <bc@freeuk.com> - 2022-11-12 11:03 +0000
          Re: xkcd: Y2K and 2038 David Brown <david.brown@hesbynett.no> - 2022-11-12 12:57 +0100
            Re: xkcd: Y2K and 2038 Bart <bc@freeuk.com> - 2022-11-12 15:56 +0000
      Re: xkcd: Y2K and 2038 scott@slp53.sl.home (Scott Lurndal) - 2022-11-12 16:05 +0000
      Re: xkcd: Y2K and 2038 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-12 18:00 -0800
        Re: xkcd: Y2K and 2038 red floyd <no.spam.here@its.invalid> - 2022-11-13 09:49 -0800
          Re: xkcd: Y2K and 2038 gazelle@shell.xmission.com (Kenny McCormack) - 2022-11-14 09:14 +0000
        Re: xkcd: Y2K and 2038 David Brown <david.brown@hesbynett.no> - 2022-11-14 10:09 +0100
          Re: xkcd: Y2K and 2038 Thomas Koenig <tkoenig@netcologne.de> - 2022-11-14 14:09 +0000
        Re: xkcd: Y2K and 2038 Klaus Wacker <klaus.w.wacker@t-online.de> - 2022-11-14 13:47 +0000
    Re: xkcd: Y2K and 2038 Paavo Helde <eesnimi@osa.pri.ee> - 2022-11-12 16:13 +0200
      Re: xkcd: Y2K and 2038 Siri Cruise <chine.bleu@yahoo.com> - 2022-11-12 15:49 -0700
    Re: xkcd: Y2K and 2038 Siri Cruise <chine.bleu@yahoo.com> - 2022-11-12 15:47 -0700
  Re: xkcd: Y2K and 2038 Klaus Wacker <klaus.w.wacker@t-online.de> - 2022-11-13 12:45 +0000

csiph-web