[SystemSafety] "Ripple20 vulnerabilities will haunt the IoT landscape for years to come"
Olwen Morgan
olwen at phaedsys.com
Thu Jul 2 17:41:54 CEST 2020
On 02/07/2020 16:12, Roderick Chapman wrote:
>
>> But, considering that a compiler for a functional language may
>> convert tail recursion to iteration, I ask whether anything in the
>> Ada standard explicitly forbids an Ada compiler from implementing
>> iteration by recursion?
>>
> Not sure... but I have never seen a compiler do this.
Praise be to the Gods that you have not!
>
> Note again - things changed a bit with SPARK2014...
>
> SPARK83 - SPARK2005 did not directly support proof of termination of
> loops, so all proof was "partial".
>
> SPARK2014 _does_ support proof of termination (for loops) through a
> user-defined "Loop_Variant" expression. Not sure about what happens
> with termination of recursive subprograms, though - I'm a bit out of
> the loop with those details. The current SPARK user guide should have
> more... yeah.. see
Well, in principle, this is an example of the kind of problem to which I
alluded. If a compiler is not banned from implementing iteration
recursively and takes advantage of latitude to do so, then the
termination of a loop may be conditional upon the compiled code
operating in an environment where it can run the loop to termination
without running out of memory. So, the next question is, do the analysis
tools take this into account when seeking to prove loop termination? If
so, great. If not, then we have identified possible circumstances in
which the analysis tools may not correctly predict program behaviour.
The more such lacunae we identify, the more it tends to cast doubt on
the idea that CbyC allows us to forgo unit-testing.
Olwen
More information about the systemsafety
mailing list