Re: What Happened While I Wasn't Looking?

[sampson@nosc.mil (Charles H. Sampson)]

     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 <E82sM5.Gwv@world.std.com>,
Robert A Duff <bobduff@world.std.com> wrote:
>In article <1997Apr2.202514.1843@nosc.mil>, Charles H. Sampson <me> 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