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,f1111f1bf805022b X-Google-Attributes: gid103376,public From: "Robert I. Eachus" Subject: Re: Unconstrained type Unchecked_Deallocation Date: 2000/04/12 Message-ID: <38F4D388.31821B3@earthlink.net>#1/1 X-Deja-AN: 610343156 Content-Transfer-Encoding: 7bit References: <8a0h55$qc5$1@nnrp1.deja.com> <38C3D82F.C9F81832@bton.ac.uk> <38C566CE.6283C0AD@rational.com> <8a6f5s$5st$1@nnrp1.deja.com> <38EBAAD6.3EA21F14@earthlink.net> <8cica0$1iu$1@nnrp1.deja.com> <38F0B641.2346CF95@earthlink.net> <8cqjjb$muu$1@nnrp1.deja.com> X-Accept-Language: en,pdf Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 955568899 63.24.57.175 (Wed, 12 Apr 2000 12:48:19 PDT) Organization: The MITRE Corporation MIME-Version: 1.0 NNTP-Posting-Date: Wed, 12 Apr 2000 12:48:19 PDT Newsgroups: comp.lang.ada Date: 2000-04-12T00:00:00+00:00 List-Id: Robert Dewar wrote: > Your discussion boils down to worrying about a class of > programmers who have the following characteristics. > > 1. They would not dream of looking in a body, and taking > liberties with information derived therefrom. > > 2. They will look at an unchecked conversion in the spec and > feel free to do stupid things. Yep, on a large project, if there is an unchecked conversion in the interface, programmers will assume that it is part of the interface and can be treated as such. These same programmers may never have the opportunity to look at the corresponding body, which may be written by a group at a different location, or even a different company. In fact, I have seen unchecked perversion where the specs were common, and the bodies were written by two different companies several thousand miles apart. Moving to a different platform was a killer... > OK, maybe there are such programmers, but I have not met them. The luxury of being an academic. ;-) That smiley is because Robert Dewar has spent as much time in the trenches as I have. I just used to get called in on the really bad cases. I literally can't tell you how many times I have been called in to declare the corpse dead--and yes, there have been a few times when it wasn't. If I can I'd like to write a paper on how to tell that a software project is dead. In one sentence, if fixing a bug will on average introduce at least one new bug, stop. The trick is to be able to determine that ahead of time, and stop earlier. (Or even on time. It is a characteristic of failed software projects that the quality of the bug report database is poor.) > I meet really two classes of programmes in this kind of respect. > 1. Those who are careful, and know that it would be folly to > depend on the representational equivalence implied by an > unchecked conversion, whether or not it is in the spec or the > body. But would never dream of putting the Unchecked_Conversion in the visible part of the package... > 2. Those who will do what they like, regardless of what is nice, > and will not hesitate a moment to draw the same (bad) conclusion > from an unchecked conversion in the body as in the spec. But to make use of the fact, they often have to put in their own instances of Unchecked_Conversion and get caught that way. > I think trying to make this out as an important methodological > issue is bogus. After all, if you have a function in the spec > whose spec is that it convers from integer to address by the > moral equivalent of unchecked conversion, then you can draw > evil conclusions just from this spec. I cannot imagine some > wonderful high level semantic description of this conversion > that is at an abstraction level different from unchecked > conversion (assuming a reasonable implementation thereof). No, the conclusions that you can draw from the function in the spec are not evil. If for example the body of a visible conversion function is an instance of Unchecked_Conversion from Integer to System.Address, and the program is moved to a different platform where the two have different sizes, then it will usually be possible to replace that body without changing the semantics. (Of course there will normally be more than one operation in the package that needs to be rewritten. But still, you are within one package body, and don't have to look throughout the program.)