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/28 Message-ID: <1997Oct28.221806.2805@nosc.mil>#1/1 X-Deja-AN: 285631937 Sender: news@nosc.mil References: <1997Oct23.205254.25272@nosc.mil> <1997Oct28.192057.29122@nosc.mil> <878068940.763599@wagasa.cts.com> Organization: Computer Sciences Corporation Newsgroups: comp.lang.ada Date: 1997-10-28T00:00:00+00:00 List-Id: In article <878068940.763599@wagasa.cts.com>, Keith Thompson wrote: >Charles H. Sampson (me) wrote: >[...] >> You are right, the GNAT implementation is entirely correct. I >> must have mislead you when I said "technically correct". Technically >> correct is correct, no doubt about it. All I meant was that GNAT is not >> following the programmer's wishes. If Suppress(Elaboration_check) is >> written, then the programmer doesn't want the check made; if the check >> is not made then Program_error can't be raised. The programmer's wisdom >> in making such a request is another discussion. >> >> Charlie > >As is the programmer's wisdom in assuming that pragma Suppress means >the check won't be made. > >The intent of pragma Suppress is to improve the efficiency of generated >code by inhibiting checks that the programmer knows will not fail. >Suppressing a check that would fail if it were not suppressed, as in >the following: > > X : Some_Integer_Subtype := Some_Integer_Subtype'Last; > > declare > pragma Suppress(Range_Check); > begin > X := X + 1; > end; > >is a misuse of the pragma, and results in erroneous execution (and >arbitrarily nasty results). For example, the compiler is entitled to >assume that X is in the range of its subtype after the assignment, and >to perform optimizations based on that assumption. The more clever the >compiler, and the more aggressively it optimizes, the more likely it is >to mess things up. A bunch of very good points and I certainly don't want to be put into the position of defending anyone who tries to achieve some result by an erroneous execution. I'm big on writing portable code and errone- ous programs (forgive the ellipsis) are anathema to me. However, I have never been happy as a programmer when a compiler says, "I'm smarter than you are and I'm not going to allow you to do what you want." When I was a compiler writer, I tried to keep my compilers from doing that. Now that doesn't quite apply to the current case, because the RM allows the programmer's "suggestion" to be ignored. Nevertheless, it's very close in spirit. The existence of Suppress(Elaboration_check) strongly indicates that the programmer wants the check suppressed, as does Suppress(Range_check). Any argument about erroneousness that is applicable to the former can also be made for the latter. Charlie -- ****** If my user name appears as "csampson", remove the 'c' to get my correct e-mail address.