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,55f243f32a97dc7e X-Google-Attributes: gid103376,public From: csampson@cod.nosc.mil (Charles H. Sampson) Subject: Re: Elaboration_check For Instantiations Date: 1997/10/27 Message-ID: <1997Oct27.221500.1918@nosc.mil>#1/1 X-Deja-AN: 285389840 Sender: news@nosc.mil References: <1997Oct23.205254.25272@nosc.mil> Organization: Computer Sciences Corporation Newsgroups: comp.lang.ada Date: 1997-10-27T00:00:00+00:00 List-Id: I suppose that the best thing to do when you make a very public boo-boo is to be quiet and hope that everybody forgets about it as soon as possible, but I'm too old to start that now. I'll "contribute" to this thread a little longer. In article , Tucker Taft wrote: >Charles H. Sampson (csampson@cod.nosc.mil) wrote: > >: Sigh. When I said that my sample code was legal in Ada 83, I >: thought I saw some loose wording in the LRM that would allow it, al- >: though it appeared that the intent was to discourage it, at the least. >: Now, however, it seems to be illegal in Ada 83 as well, by 3.9(7). > >Actually, it is not illegal. It "simply" raises Program_Error >at run-time (in Ada 83 and Ada 95), due to violating the checks >regarding access before elaboration. In any case, there was no >change in the rules in this area between Ada 83 and Ada 95. >Apparently the wording in Ada 95 is clearer on the subject >(at least to you ;-). You're right about that. I do find the new wording clearer. > >: When I said that it worked in several compilers, I know of at >: least three. When I said that a healthy body of code exists using the >: "feature", that body includes a large number of packages supplied by an >: Ada compiler vendor! > >Well, then I guess these compilers all had a common bug. Alternatively, >the code was compiled with Elaboration_Check suppressed. You >could add "pragma Suppress(Elaboration_Check);" to the above code, >and it would probably not raise Program_Error (though it would then be >officially erroneous, per RM95 11.5(26)). One of the compilers that I thought accepted this construct actu- ally disallows it, but in a non-standard manner. (This is a very highly respected Ada 83 compiler.) It compiles that entire package, specifica- tion and body, with no warnings. No "Execution of this construct will cause Program_error to be raised." However, when you try to link the programs, you're told that the specification is obsolete. In other words, the spec compiles o. k., but compiling the body obsoletes the spec. Of course, recompiling the spec will obsolete the body, etc. I think I know where I went wrong on this whole issue. We've been given the task of porting an Ada 83 program, moving it to Ada 95 at the same time. As part of our contract we've been given the Ada 95 compiler that we must use and the existing Ada 83 code, but not the compiler that that code was compiled with. We have been assured that this code is ex- actly the code of the current running program. I probably should have taken that assurance with a grain of salt. Charlie -- ****** If my user name appears as "csampson", remove the 'c' to get my correct e-mail address.