From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,7b69a8818c20ab9f
X-Google-Attributes: gid103376,public
From: Robert A Duff <bobduff@world.std.com>
Subject: Re: Y21C Bug
Date: 2000/01/03
Message-ID: <wccg0wfb02q.fsf@world.std.com>#1/1
X-Deja-AN: 567790349
Sender: bobduff@world.std.com (Robert A Duff)
References: <84nqbo$q28$1@nnrp1.deja.com> <84o0g2$u8v$1@nnrp1.deja.com>
 <84pvrs$7q1@ftp.kvaerner.com>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 2000-01-03T00:00:00+00:00
List-Id: <comp.lang.ada>

"Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes:

> Robert Dewar wrote
> >
> >Note by contrast that when the Unix date runs out of 32 bits,
> >this will cause QUITE a bit of disruption to existing programs
> >and be quite a bit more difficult to fix.
> >
> 
> 
> Only if there are any 32 bit unixes around at that time - 2038. Many of us
> reading this will not be around then :-(. As far as I know all 64 bit unixes
> uses a time_t size of 64 bit.

And from what I've heard, making Unix code "64-bit clean" hasn't been so
easy, which is exactly the sort of thing Robert Dewar was talking about.

If it were as easy as changing some "Word_Size" constant, then people
wouldn't have invented a fancy term like "64-bit clean" for it.  ;-)

- Bob