ID0000997: **This issue was created automatically from Mantis Issue 997. Further discussion may take place here.** --- | **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** | | --- | --- | --- | --- | --- | --- | | ID0000997 | Frama-C | Plug-in > Eva | public | 2011-10-23 | 2012-09-19 | | | | | | | | | --- | --- | --- | --- | --- | --- | | **Reporter** | yakobowski | **Assigned To** | yakobowski | **Resolution** | fixed | | **Priority** | normal | **Severity** | minor | **Reproducibility** | always | | **Platform** | - | **OS** | - | **OS Version** | - | | **Product Version** | Frama-C Nitrogen-20111001 | **Target Version** | - | **Fixed in Version** | Frama-C Oxygen-20120901 | ### Description : Consider the following program analyzed with frama-c -val -absolute-valid-range 0-100 const short max = 255; const short min = 0; extern float u[256]; float main () { short r; float f = *((float *)18); // assert -3.40282346639e+38 <= f <= 3.40282346639e+38; int j = 2; // To be able to see the value of f in the gui if(f >= max) r = max; else if (f <= min) r = min; else r = f + 0.5; return u[r]; } The results are not optimal, as the access to u[r] is not proven correct. The reason is as follows: with a "normal" float, the reductions within the 'if' take place normally, and r belongs to [0..255]. However, here we have a Topint inside a float, and the reduction does not happen. If we activate the assertion to help the user, the result is worse: the assertion is incorrectly proven correct, as the conversion to a finite float happens before the truth value of the assertion is computed. Moreover, since the assertion is "correct", no reduction by the assertion occurs, and the access to u[r] is still not correct.