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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: What Happened While I Wasn't Looking? Date: 1997/04/07 Message-ID: <1997Apr7.182117.22958@nosc.mil> X-Deja-AN: 231403464 Sender: news@nosc.mil References: <1997Apr2.202514.1843@nosc.mil> Organization: Computer Sciences Corporation Newsgroups: comp.lang.ada Date: 1997-04-07T00:00:00+00:00 List-Id: My thanks to Bob for his response to my post. I truly appreciate it. Unfortunately, I don't agree with much of it, so I follow up. I apologize for the length of this post. I've cut it down as much as seems possible, but it's still pretty long. In article , Robert A Duff wrote: >In article <1997Apr2.202514.1843@nosc.mil>, Charles H. Sampson wrote: > >> The majority of my career has been spent in maintenance program- >>ming, with almost all of that in FORTRAN and CMS-2. Based on my experi- >>ence, the single greatest cause of maintenance problems (bugs) and >>enhancement difficulties is the overlay. > >Ah, but overlays are *not* a big cause of maintenance problems in Ada 83 >or Ada 95. This isn't because they're forbidden -- it's because they're >not needed most of the time. > I agree, to a point. Certainly most of the overlaying that I've seen in both CMS-2 and FORTRAN arose as an attempt to get around short- comings of those languages, shortcomings that Ada doesn't have. How- ever, I'm pretty sure that overlaying through address clauses being erroneous has helped keep it down to some degree. (See below.) >>... When I taught Ada 83 I pointed out this issue and used it as a >>selling point, saying that overlaying was impossible in a non-erroneous >>Ada program. > >I don't understand how this can be a benefit. Ada compilers are not >required to detect erroneous things (neither at compile time nor at run >time). So how can it be beneficial (in terms of eliminating bugs) for >the RM to declare something erroneous? > It depends on how you treat erroneousness. I've been surprised at some of the responses to this thread that seem very close to relishing the erroneous constructs as potentially nice holes that can be exploited when necessary. When I taught Ada 83 I pointed out that they have no language defined semantics, a compiler is not required to detect them and often can't, and, even if you discover what the semantics are for your particular combination of compiler and target computer, there's a very good chance that it's not portable and they might even change in the next version of the compiler. Conclusion: Avoid them. (By the way, I know the drill. I'm using "erroneous construct" as a convenient shorthand for the much longer, technically correct, phrase.) > >Anyway, IMHO, a language definition should not try to "prevent evil" so >much as "encourage good". ... > That's at least an arguable point. Carried to its extreme, which I know is not being advocated here, you get to the point of saying, "Put anything at all into the language, provided you've included good ver- sions of all the bad things." Certainly the effort that culminated in Ada 83 had a lot of "do not allow" guidelines. >> ... I went on to extol the virtues of Unchecked_conversion, in >>particular the point that it makes the "aliasing" obvious at the point >>where it is being used. > >Well, unchecked conversions can be erroneous, too, in some cases. > Yes, they can, and they can be non-portable as well. Rephrasing the point that I tried to make before: The advantage of Unchecked_conversion is that it is "self-flagging". Every place that it appears in the source code is a potential trouble spot that has to be investigated when porting. In the case of overlaying, it's not the overlay itself that must be investigated, but every reference to the two objects involved. Probably most of those references will be benign. >Also, note that unchecked_conv can create aliases, in some cases. The >obvious case is that you can convert from an address or access value to >an access value, which, if it works at all, which it does on most >compilers for most data types, creates an alias. It seems to me that >these kinds of aliases are just as damaging as the ones created by >Address clauses. > I don't follow this. You seem to be saying that because an access value can sometimes (often) be created using Unchecked_conversion, then it can create aliases. I'll concede that, but it seems to me to be no- thing more than the general problem of aliasing through pointers. >A lesser-known case is 13.9(12), "An implementation may return the >result of an unchecked conversion by reference, ...". This was also >true in Ada 83, by virtue of an AI (though the original RM83 didn't say >so). The reason for this rule is efficiency. Furthermore, >implementations are *encouraged* to do the by-ref thing, in 13.9(15). >It can create aliases, which is why the explicit permission is needed, >since functions normally return their results by copy. > This is off my main subject, but maybe somebody can explain 13.9(15) to me. I find it unusual for a language definition to say, "A compiler may generate code to implement the semantics of this feature." >> ...Now I will be forced to admit that the beast is >>alive and kicking, at least to some degree, in Ada 95. > >Methinks you exaggerate. Just because the RM has changed, doesn't mean >everybody is going to go out and sprinkle address clauses all over their >code. ... No, certainly everybody isn't going to do that. There's a large body of software engineers out there who, like me, look upon Ada as a gift from the gods. On the other hand, there are a lot of Ada program- mers, the kind that used to be called hackers, who will try anything to "get the job done". They might even be anti-Ada. (Let's avoid discus- sion of the mandate. Such people could be part of the troops on a large project whose leaders have chosen Ada for reasons that have nothing to do with the mandate.) If their mindset is such that they don't see any- thing wrong with overlays, they'll try to use them. I know of one CMS-2 to Ada translator that uses address clauses in Ada 83 to translate the CMS-2 overlay. This translator was created by a group that should know better, who should understand at least the port- ability implications of the code they are generating. Never mind that simply forcing two objects to share memory is no guarantee that the CMS-2 semantics have been reproduced. >> My primary question is, why was this change made? > >First of all, the change was not to simply eliminate the Ada 83 rule. >The rule was replaced by 13.3(13), which says almost the same thing, and >certainly lets one know of the potential evils of this feature. > Wait a minute! The injunction in Ada 83 is against overlaying ob- jects and program units. 13.3(13) says that the programmer must ensure that the address given in an address clause is valid. Other than the appearance of the word _erroneous_, I see no connection between them. (The term _valid address_ appears to be undefined in the RM--at least it's not in the index--so I have to guess that it means things like en- suring word or paragraph alignment when required by the datum.) >I think the change was made for these reasons: > >(1) It's hard to formally define what an "overlay" is. I mean, suppose >you use an Address clause to put an Ada variable at a location that is >some sort of I/O control register. Is that an overlay? In some sense, >it is -- you're overlaying the Ada variable with a non-Ada "variable". >But this is exactly what Address clauses are *for*. Does "overlay" only >mean overlaying two Ada variables? Why? > When I use the term _overlay_ I mean two objects sharing memory. That's what I meant in my original post. As to why, because I'm pretty sure that that's what most people mean by the term. What you're refer- ring to here I call "mapping to memory" and I agree that that is exactly what address clauses used to be for. I see only the slightest connec- tion between the two. >(2) In practise, although Ada 83 programmers didn't use address_clauses >much, when they did, they sometimes used them to make overlays, and >their programs worked fine (albeit non-portably). ... They sometimes worked fine for a particular version of a particu- lar compiler for a particular target computer. > ... It seems silly to >insist that common practise is erroneous. ... The above seems to me to be exactly why such a usage should be classified as erroneous. > ... The real rule is that you >have to know what sort of code your compiler is generating, and that's >what 13.3(13) says. > Again, I can't read 13.3(13) that way. >(3) Other features are just as "evil" (for example unchecked conversion >of access values). Why single out address clauses? > Again, Unchecked_conversion is a lesser evil because of its self- flagging nature. Also, Unchecked_conversion is being used for precisely the purpose it was designed for, albeit in a non-portable application when used to generate access values. >(4) Overlays can be useful (but you have to be careful, if you're going >to avoid maintenance headaches). > >(5) It's possible to encapsulate one's use of overlaid storage. > I'd like to see examples of both of these claims. In particular, I'd like to know what the "be careful" rules are that are going to avoid maintenance headaches. Remember, my long experience is just the oppo- site, that overlaying causes maintenance headaches. I need to be con- vinced that all of that experience is anomalous. >> The saddest aspect of this mistaken change (my opinion, obviously) >>is that it doesn't adequately support overlaying. Even if a compiler >>implements the recommended level of support (RM 13.3(12-19)) it is only >>required to do the right thing for the one of the overlaid data whose >>address has been specified (RM 13.3(19)). > >If you make the other variable "aliased", then you'll be OK. > You get reluctant o. k. from me on that one. It seems to me to be very close to lying to the compiler and maintenance programmer again, although technically it isn't. I think the implication is that aliased objects will be designated by access values, but nothing in the RM that I can find says that that is the purpose of aliasing. [An example illustrating the kind of knots that you can get tied into using address clauses to overlay has been deleted. To me, this ex- ample illustrates why such stuff should not be allowed.] >> It's interesting to note that GNAT handles the two package example >>"right". My guess is that that's a result of GNAT's treating package >>specifications like include files. On the other hand, GNAT (PC version >>3.07) allows one of the overlaid objects to be a constant and the other >>to be variable. Furthermore, the generated code allows the value of the >>constant to be changed. This is clearly a bug, either in GNAT or the >>language specification. It is not prohibited in RM 13.3. Is it prohib- >>ited elsewhere? > >No, except that 13.3(13) allows the compiler to declare this case >erroneous. I'm impressed. Apparently 13.3(13) can be read to say: If an ad- dress clause causes a bad effect, then the specified address was invalid and the program is erroneous. I certainly don't get any comfort out of such a flexible reading. Charlie