comp.lang.ada
 help / color / mirror / Atom feed
From: "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com>
Subject: Re: Y21C Bug
Date: 2000/01/06
Date: 2000-01-06T00:00:00+00:00	[thread overview]
Message-ID: <85201l$7q3@ftp.kvaerner.com> (raw)
In-Reply-To: 8505tc$be4$1@nnrp1.deja.com


Robert Dewar wrote
>I can just imagine someone saying in 1985 (easy to imagine,
>because it is based on memories of hearing this said often)
>
>"I expect support for COBOL-74 and related applications to be
> phased out by the end of the decade, and we should not have
> any trouble with the date change in 2000 because all old
> applications will be phased out by then, and all new
> applications are being written to be aware of this problem"

That is an entirely different matter. There are other dynamics involved. E.g.
incompatibilities between operating system versions. Programs cannot determine
disk sizes in bytes because a 32 bit int is becoming too small. Some files are
becoming so large that one needs more than 32 bit ints to store the size. I'm
sure others can point to other such 32bit annoyances.

These things and more add up to a slow pressure to phase out old 32bit
programs. Note the use of the word old. If the new 32bit API does not take into
account these things, then it too will disappear. It will take more time, but
they will disappear. Whether it takes 10 or 20 years I'm not certain, but they
will disappear.

y2k bagged a lot of old programs (on the PC side where I work they retired
approximately 600 applications. On the Unix side we got new versions which were
y2k compliant), further change will do in more.

>Tarjei gives absolutely NO documentation for his expectations,
>he seems to have just based them on what seems reasonable.
>
>The actual facts are that old software stays around for a long
>time. Look for example at the situation on -o32 with SGI. SGI
>would surely like to get rid of this old ABI, and pushes
>customers hard to move to the new much more efficient -n32
>ABI, but there are still many 3rd party libraries etc which
>have not made the switch.

But the change is being made. As of today -o32 is a problem since we cannot
mix -o32 and -n32 and that pushes towards -n32. Slowly, but surely.

The previous version of gcc I used on Irix generated -o32 object files. The one
I use now generates -n32 and is very unwilling to generate -o32 object files.
In fact I am certain that as the 32bit SGI machines falls into disuse -n32 will
disappear as well. I suspect that if Irix survives 20 years from now it will be
with very reduced 32 bit support.

>I think you *greatly* underestimate the time scale for 32-bit
>mode disappearing.
>
>No vendor has indicated any push in the direction of eliminating
>32-bit mode support.


I suggest you re-read what I wrote. I wrote that old 32bit mode would
disappear. Which probably means -o32 disappears. I have not claimed that the
equivalent of -n32 would disappear within a decade. I suspect that it will
disappear within 20 years if it does not become 64 bit compliant. E.g. support
big files and a 64 bit time.


Greetings,







  parent reply	other threads:[~2000-01-06  0:00 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-01-02  0:00 Y21C Bug reason67
2000-01-02  0:00 ` Robert Dewar
2000-01-03  0:00   ` Tarjei T. Jensen
2000-01-03  0:00     ` Jeff Creem
2000-01-03  0:00       ` Tarjei T. Jensen
2000-01-03  0:00     ` Robert A Duff
2000-01-04  0:00       ` Robert Dewar
2000-01-04  0:00         ` Charles Hixson
2000-01-04  0:00           ` Keith Thompson
2000-01-05  0:00           ` Robert Dewar
2000-01-05  0:00           ` Robert Dewar
2000-01-05  0:00             ` Y21C Bug :-) Charles Hixson
2000-01-06  0:00               ` Ted Dennison
2000-01-07  0:00                 ` Keith Thompson
2000-01-07  0:00                   ` Robert A Duff
2000-01-04  0:00       ` Y21C Bug Tarjei T. Jensen
2000-01-04  0:00         ` Robert Dewar
2000-01-05  0:00           ` Tarjei T. Jensen
2000-01-05  0:00             ` Robert Dewar
2000-01-06  0:00               ` Georg Bauhaus
2000-01-06  0:00                 ` Tarjei T. Jensen
2000-01-06  0:00               ` Richard D Riehle
2000-01-06  0:00               ` Tarjei T. Jensen [this message]
2000-01-06  0:00                 ` Larry Kilgallen
2000-01-05  0:00             ` Al Christians
2000-01-06  0:00               ` Tarjei T. Jensen
2000-01-06  0:00                 ` Robert Dewar
2000-01-06  0:00                   ` Robert A Duff
2000-01-06  0:00                     ` Larry Kilgallen
2000-01-07  0:00                     ` Florian Weimer
2000-01-07  0:00                       ` Robert A Duff
2000-01-07  0:00                         ` Robert Dewar
2000-02-04  0:00                           ` Florian Weimer
2000-02-04  0:00                             ` Robert A Duff
2000-02-04  0:00                               ` Florian Weimer
2000-01-11  0:00                         ` Mats Weber
2000-01-11  0:00                           ` Robert A Duff
2000-01-12  0:00                             ` Mats Weber
2000-01-12  0:00                               ` Thierry Lelegard
2000-01-13  0:00                                 ` Robert A Duff
2000-01-13  0:00                                   ` Thierry Lelegard
2000-01-13  0:00                                   ` Larry Kilgallen
2000-01-13  0:00                                 ` Mats Weber
     [not found]                               ` <387dfb1e.cbbf14c7@mail.com>
2000-01-13  0:00                                 ` Larry Kilgallen
2000-01-11  0:00                     ` Mats Weber
2000-01-07  0:00                   ` Tarjei T. Jensen
2000-01-07  0:00                     ` Robert Dewar
2000-01-06  0:00               ` Robert Dewar
2000-01-04  0:00         ` Samuel Tardieu
2000-01-04  0:00         ` Robert A Duff
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox