Re: GNAT 3.01 Source For OS/2

[heatwole@erols.com (Kevin D. Heatwole)]

In article <dewar.831148051@schonberg>, 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.