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,9a586954b11ae008 X-Google-Attributes: gid103376,public From: sampson@nosc.mil (Charles H. Sampson) Subject: Re: Overflows (lisp fixnum-bignum conversion) Date: 1997/04/09 Message-ID: <1997Apr9.145543.1998@nosc.mil>#1/1 X-Deja-AN: 231819626 Sender: news@nosc.mil References: <1997Apr2.202514.1843@nosc.mil> Organization: Computer Sciences Corporation Newsgroups: comp.lang.ada Date: 1997-04-09T00:00:00+00:00 List-Id: In article , Robert A Duff wrote: > >Remember that this was all in response to somebody who claimed that >declaring a certain feature of Ada 83 "erroneous" somehow made this >feature of Ada 83 safer, than corresponding features in other languages >that require the feature to "work" (such as Ada 95). I disagree with >that. > Hold on! I'm pretty sure you're referring to me, the guy who started this thread, and I said no such thing. It's beyond me how what I originally said could have been interpreted that way, but I later elaborated. Repeating: In my shop, erroneous means not checked by the compiler (maybe not checkable) and compiler dependent, ad hoc, seman- tics; therefore don't use. Ada 83 had a pretty short list of erroneous constructs, so it was generally easy to avoid them. Not always. Some were treacherous, such as referencing an actual parameter directly and through its correspond- ing formal parameter, which fortunately doesn't arise very often in a well-designed program. In any case, that's an aliasing problem and my original complaint was that by adding overlays to Ada 95 another form of aliasing is made available, with its attendant impact on maintenance and enhancement. Ada 83 had pretty well minimized aliasing to those cases that were unavoidable in any practical sense. Charlie