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,5752ba976f4dad11 X-Google-Attributes: gid103376,public From: heatwole@erols.com (Kevin D. Heatwole) Subject: Re: GNAT 3.01 Source For OS/2 Date: 1996/05/05 Message-ID: #1/1 X-Deja-AN: 153118861 references: organization: Erols Internet Services newsgroups: comp.lang.ada Date: 1996-05-05T00:00:00+00:00 List-Id: In article , dewar@cs.nyu.edu (Robert Dewar) wrote: > Going back to the constraint error situation, I can actually give the > specific example where this caused trouble. In the 2.04 release, ew > had a problem that certain error messages caused constraint errors. > There weren't any instances of these messages in our regression suite > so we had missed this (now of course there are dozens of instances of > those messages). > > This turned out to be just a matter of natural vs integer. We had turned > on constraint checks for the release to increase the reliability, and > oddly, if had significantly decreased the reliability. That was the point > at which we realized that constraint chceks had never been useful to us > anyway given our assertions (which are pretty extensive, the front end > spends 80-90% of the execution time executing assertion statements), > so we removed them and never put them back. > > Actually in the near future, we may release without the assertion checks. > It is possible that the constraint checks will then prove useful again, > we are currently making some measurements to find out what the best > apporach is. This is actually an interesting topic. Do constraint_error checks in Ada actually decrease reliability for programs? I don't know the answer since I am just a lowly Ada programmer. I know that since I have been working on Ada compilers since 1983 (and currently work for OC Systems), that in the compiler domain, these constraint_errors often are the problems that users of a compiler will report. They are also problems that sometimes contribute to the user thinking that the compiler is crap. I agree that often these violations of subtype ranges don't represent serious problems (but sometimes they do). I have always felt that the more errors caught by the language (even if these errors are not caught until runtime), the better it is for the stability of the program (in the long run). Do the C people have it right? Is it sufficient to rely on the programmer to place appropriate assertion checks to ensure reliability and that automatic range checking actually hurts? As an aside, I will note that some early compiler vendors expected that real programs would be deployed with all checks suppressed. This was because it was perceived that the overhead of making the checks would be too high in the operational environment. They expected the users to use exception checking during development/testing to weed out the problems and then remove them sometime during the development cycle. (It appears that ACT may be doing just the opposite - suppressing the checks early on and turing them on late in the cycle). Anyway, as a result, several early compiler vendors did not spend a lot of effort trying to minimize the number of exception checks emitted by their compilers (kind of a self fulfilling prophecy since the more redundant exception checks left in the operational code, the more likely that users would find reason to suppress them for performance). Around 1988 or so, things seemed to change and most user programs are deployed with full exception checking (at least, the ones I have worked with). Kevin Heatwole OC Systems, Inc.