Re: Tests in a software release

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:osvvds$s97$1@gioia.aioe.org...
...
> No. The contract requires Constraint_Error propagation. Disabling checks 
> breaks that.

I agree.

> The intention of allowing checks being disabled was to allow manual 
> optimization in very few cases when the preconditions are known to be 
> stronger than specified. The source of this knowledge is unknown, it is up 
> to the code maintainer to assert it. For this reason disabling checks 
> cannot be the rule in contrary to what Victor suggested.

I think the main reason for allowing disabling checks had to do with the 
practicalities of computer systems in the late 1970's and early 1980's when 
this part of Ada was originally defined. Back then, memory and CPU time was 
at a premium, optimization technology (especially that regarding checks, 
which few languages had) was not very advanced, and disabling checks could 
make the difference between being able to run a program and not.

Early versions of Janus/Ada disabled all checks just so that more space was 
available for symbols (the first CP/M versions of Janus/Ada had only 56K of 
RAM to run in!).

But in modern compilers, optimization technology is much more advanced, 
checking optimization is something that hundreds of man hours has been spent 
on in every Ada compiler, there is plenty of CPU for general computation, so 
checks should be disabled only in very limited contexts if at all.

Pretty much I only know of three cases: (1) profiling has shown that a 
particular routine is too slow, and suppressing checks for that single 
routine improves the performance of the application; (2) a tool like SPARK 
has been used to prove exception absence for a program with detailed 
code-level verification requirements; suppressing the checks that raise 
those exceptions already proved to be absent cuts the verification 
requirements; (3) a routine implementing something like saturation math is 
being implemented, and suppressing the range and overflow checks makes a 
cheaper implementation.

And personally think that (1) and (2) are better handled in the compiler by 
careful use of subtypes (and in the case of (2), additional warnings if an 
unexpected check is generated). And it's really unclear if (3) is better 
than just handling the exception(s) (and using Unsuppress to ensure no one 
turns off the checks).

Thus I think all style guides should treat pragma Suppress much like Goto 
and Abort, requiring a detailed justification for any usage at all. (Indeed, 
I'd much rather use a Goto, it's much less likely to cause a problem.)

                                           Randy.