Re: Tests in a software release

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

"G.B." <bauhaus@notmyhomepage.invalid> wrote in message 
news:oul0ra$jee$1@dont-email.me...
> On 15.11.17 23:17, Randy Brukardt wrote:
>
>> ...
>>> The most important thing is, designing by contract
>>> is *not* programming defensively. By definition.
>>
>> One *always* programs defensively.
>
> Why would that be?

Because the real world is a nasty place where unexpected things go wrong. 
The fewer assumptions a human has to make, the the better. A computer 
program can handle making assumptions much better, because it can juggle 
many of them and will not get confused.




> FTR, and for what the definitions are,
>  http://se.ethz.ch/~meyer/publications/computer/contract.pdf
>
> Referring to some notes from your blog, you cannot always
>
>   - compute things at compile time, hoping to optimize;
>   - perform run-time checks in a timely fashion, without
>     checks causing timeouts:

My blog was exclusively talking about language-defined constructs and 
checks. None of the rules described in the blog have any effect on 
user-defined operators (that is, ordinary function calls) because the 
compiler cannot know what the body does. Indeed, my entire discussion here 
has been about pragma Suppress and does not necessarily apply to 
user-defined contracts (that is, pragma Assertion_Policy as applies to 
things like Pre and Post).

There is absolutely no connection between pragma Suppress and pragma 
Assertion_Policy in Ada -- they work entirely differently 
(Assertion_Policy(Ignore) cannot by itself cause erroneous execution, while 
pragma Suppress almost always can).

A lot can be done with user-defined contracts, but that depends on contract 
aspects not defined in Ada 2012 (like Global, which hopefully will be in Ada 
2020). As you note correctly, timing issues might still require using 
Ignore, since it is easy to write very expensive predicates that cannot be 
left in a production system.

I believe that latter problem is a flaw in the contract system as written; 
most predicates are *not* expensive (think Is_Open in Text_IO) and thus have 
no need to be Ignored; it would be best if the occassional expensive 
predicate could be flagged and only those ignored. But again, none of that 
has anything to do with what I was discussing.

...
> On the contrary: you write the contract's clauses of
> all parties to your compiler and then, once you
> know your code meets the requirements of the contracts,
> you drop checking code accordingly ("optimize") and in
> good conscience.

Never for language-defined checks; there is no point as any barely competent 
compiler will drop them automatically for free. If it can't drop them, it's 
highly likely that your code has a bug. User-defined contracts are a 
different deal; I'd prefer to never eliminate them, either, but I recognize 
that a few are going to be too expensive, and it's not as clear that the 
compiler will be able to optimize them (although in many cases, it will be 
able to do so to get sufficient performance).

...
>    if X /= X or else X /= X then
>
>       --  what, at compile time,
>       --  for which which kind of X?

This is dubious for *ANY* kind of X. This is just a warning because X might 
be something with a side-effect and thus this might actually mean something 
other than the nothing that it appears to mean -- but even in such a case, 
the code is clearly tricky and it would be better written some other way 
that is less tricky to a reader that doesn't necessarily know the details of 
X.

This is all explained in detail in the blog and I'm not sure why you are 
asking about it here.

                                              Randy.