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: "Tarjei T. Jensen" Subject: Re: Y21C Bug Date: 2000/01/06 Message-ID: <85201l$7q3@ftp.kvaerner.com>#1/1 X-Deja-AN: 569058354 Content-Transfer-Encoding: 7bit References: <84nqbo$q28$1@nnrp1.deja.com> <84o0g2$u8v$1@nnrp1.deja.com><84pvrs$7q1@ftp.kvaerner.com> <84sltt$7s3@ftp.kvaerner.com> <84t966$be0$1@nnrp1.deja.com> <84vev2$7p4@ftp.kvaerner.com> <8505tc$be4$1@nnrp1.deja.com> Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Organization: Kv�rner Group IT Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-01-06T00:00:00+00:00 List-Id: 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,