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,start X-Google-Attributes: gid103376,public From: sampson@cod.nosc.mil (Charles H. Sampson) Subject: What Happened While I Wasn't Looking? Date: 1997/04/02 Message-ID: <1997Apr2.202514.1843@nosc.mil>#1/1 X-Deja-AN: 230327131 Sender: news@nosc.mil Organization: Computer Sciences Corporation Newsgroups: comp.lang.ada Date: 1997-04-02T00:00:00+00:00 List-Id: The Prologue, being information fascinating to all and necessary to un- derstand the author's position before reading The Questions: I was unlucky enough to be heavily involved with "something else" during most of the Ada 9X work. I know many people were, but in my case it really minimized the time I could devote to even following the work, much less trying to contribute to it. In spite of that, I have been congratulating myself on understanding the major changes pretty well, the OO features, child packages, etc. That self congratulation might be well founded, but I've certainly been stung several times when I stum- bled across little tweaks that I failed to notice. My most recent dis- covery is that the Ada 83 injunction against using address clauses to cause overlaying has been dropped. 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. Colleagues agree with this opinion. 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 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. Now I will be forced to admit that the beast is alive and kicking, at least to some degree, in Ada 95. The Questions: My primary question is, why was this change made? Was the negative impact on maintenance considered? I haven't found anything on the issue in the Rationale. I've misplaced my copy of the AARM, but I wouldn't expect to find anything on it there. Robert Dewar has pointed out that there are efficiency gains coming from never having to do a copy when changing from one view to another. Was that the only consideration? The Epilogue, being divers observations on the issue: 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)). To the response that a com- piler implemented to minimally satisfy the requirement would be very poor, consider the example used to demonstrate why overlays through ad- dress clauses couldn't work in Ada 83: The overlaid data come from dif- ferent package specifications. A conventional Ada compiler, retrieving information about the packages from its library, would probably find that only one of the data should be treated conservatively. (The much maligned CMS-2, which raised aliasing to undreamed of heights, had a rule preventing this kind of thing.) I suppose it would be possible after compiling the second package specification (the one that contains the address clause) to modify the library information for the first package, but how many compilers do this kind of thing? Robert has written that he always uses pragma(volatile) on both data to make sure the overlay works. That should do the trick, but I see two problems; there may be more. The first is that code that reads the overlaid data becomes overly conservative, fetching them every time rather than ever using an in-register value. (This seems to weaken the claim of efficiencies made for the feature.) The second is that it amounts to lying to the compiler and, more important, to the maintenance programmer. According to RM C.6(1), pragma(volatile) is used to "con- trol the use of shared variables". While it might seem like a harmless white lie to tell the maintenance programmer that a non-shared variable is shared, in my experience any lie in programming eventually comes back to haunt you, usually at the most inopportune moment. 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? Charlie