Skip to content

invalid loop invariant marked as valid (without pending hypothesis)

ID0001462: This issue was created automatically from Mantis Issue 1462. Further discussion may take place here.


Id Project Category View Due Date Updated
ID0001462 Frama-C Plug-in > wp public 2013-07-29 2014-03-13
Reporter virgile Assigned To correnson Resolution fixed
Priority normal Severity major Reproducibility always
Platform - OS - OS Version -
Product Version Frama-C GIT, precise the release id Target Version - Fixed in Version Frama-C Neon-20140301

Description :

Given the program below, wp discharges all proof obligations, including the first loop invariant whose preservation is false. This allows then to prove the invalid assertion after the loop. It seems that all three loop invariants (with their \at() term) are necessary to reproduce the issue.

Additional Information :

-- file.c void f(int c) { int x = 0; int y = 0; /*@ assert for_value: c<= 0 || c == 1 || c>=2; / if (c==2) { x=1; y=1; } L: /@ loop invariant \at(x==0,L) ==> i!=0 ==> y == 0; loop invariant \at(x==1,L) ==> i!=0 ==> x == 1; loop invariant \at(c==0,Pre) ==> i==0 ==> x == 0; loop assigns i,x,y; / for (int i = 0; i<10; i++) { if (c == 0) { x = 0; } if (c == 1) { y = 1; } if (c == 2) { x = 1; } } if (c==1) { /@ assert consequence_of_false_invariant: y==0; */ } }

Steps To Reproduce :

frama-c -wp file.c One can see the inconsistent status (green/black bullet) of the assert with frama-c-gui -wp file.c -then -val -main f -slevel 100

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information