<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 02/07/2020 16:56, Roderick Chapman
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9b285103-1788-3ee0-5c28-521a61862729@proteancode.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</blockquote>
<snip><br>
<blockquote type="cite"
cite="mid:9b285103-1788-3ee0-5c28-521a61862729@proteancode.com">
<p><font size="+1">As for a compiler maliciously turning iteration
into recursion... I have never seen this in 30-odd years of
compiling and running SPARK programs, so it's not something
that I'm ever gonna lose sleep over.</font></p>
<p><font size="+1"> - Rod</font></p>
</blockquote>
<p>Neither have I, nor will I lose any sleep over it.<br>
</p>
<p>But it does suggest more generally that the premises on which
tools rely currently probably cannot all be derived from the
wording of a language standard. If we are going to rely on CbyC as
a production engineering technology, we must ensure, as far as is
reasonably possible (AFAIRP) that we have due traceability for the
assumptions that underpin our use of it.</p>
<p>In saying AFAIRP, obviously I am admitting the possibility of a
risk-based approach. That in turn will depend on the details and
the numbers. I'm willing to be persuaded otherwise but right now,
my gut instinct is that, while risk data may look encouraging,
they're probably not strictly enough to justify abandoning
unit-testing in all cases. Consider the following hypothetical
dialogue in a liability case in court:</p>
<p><br>
</p>
<p>Lawyer: Can you prove that you tested the unit of code to which
the failure was traced?</p>
<p>Engineer: No. We relied on CbyC rather than systematic coverage
in unit-tests.</p>
<p>Lawyer: I rest my case.</p>
<p><br>
</p>
<p>I'd never put myself in that position in the witness box. As the
WHO said: TEST, TEST, TEST.</p>
<p><br>
</p>
<p>Olwen</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>