--- layout: fc_discuss_archives title: Message 4 from Frama-C-discuss on January 2020 ---
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Frama-c-discuss] Strange results when verifying bitshifts using frama-c v19.1 with z3



Thanks, I’ll update it right away!

This makes me wonder though..
How do I know if I get another false positive again?
Should I always check that the opposite of what I’m trying to prove is false? Or how do you guys handle issues like this?

// Nauck
> On 10 Jan 2020, at 09:49, Loïc Correnson <loic.correnson at cea.fr> wrote:
> 
> Hi,
> Actually, there was probably a bug in 19.1 regarding right-shift, which has been fixed in 20.0 ;
> Indeed, you shall upgrade to the new version.
> Debugging z3 output is not _yet_ available, since we need some extra support from why3 for doing so.
> You can however get the prover output with `-wp-msg-key prover` and have the why3 task for each prover logged down with `-wp-out <dir>`.
> Regards,
>    L.
> 
> 
>> Le 9 janv. 2020 à 22:47, Benjamin Nauck <benjamin at nauck.se> a écrit :
>> 
>> Hi,
>> I know v20 is out and I should probably update but I've got some questions about the behaviour of v19.1 that I would like to have the answer to.
>> 
>> The problem is that I get some strange result when using frama-c v19.1 with why3 v1.2.1 and z3 v4.8.6 (running on macos 10.14.1).
>> It seems to starts when I have bit shift in the code I'm trying to verify, as seen in the following example:
>> 
>> $ cat test.c
>> //@ ensures \result == 0; ensures \result != 0;
>> unsigned test(unsigned value) {
>>    return value >> 1;
>> }
>> $ frama-c -wp -wp-prover=z3 test.c
>> [kernel] Parsing test.c (with preprocessing)
>> [wp] Warning: Missing RTE guards
>> [wp] 2 goals scheduled
>> [wp] Proved goals:    2 / 2
>>  Qed:             0  (0.38ms-0.82ms)
>>  Z3:              2  (140ms)
>> 
>> 1. Maybe I'm missing something, but to me, \result should neither be always 0 nor never 0 and it should especially not be both at the same time, right?
>> 
>> 2. Any idea what could be causing this?
>> 
>> 3. Is there a way to read the output of why3 and z3 to try to debug what is happening without diving into the source code of frama-c or the configuration files of why3?
>> 
>> I've put off upgrading to v20 as I need to verify quite a lot of bit manipulation of integers and I've got the impression that the new version is a bit buggy when it comes to that (even though workarounds seems to exist).
>> 4. Should I upgrade to v20 anyway or am I better off with 19.1 for that?
>> 
>> Regards,
>> Benjamin Nauck
>> _______________________________________________
>> Frama-c-discuss mailing list
>> Frama-c-discuss at lists.gforge.inria.fr
>> https://lists.gforge.inria.fr/mailman/listinfo/frama-c-discuss
> 
> _______________________________________________
> Frama-c-discuss mailing list
> Frama-c-discuss at lists.gforge.inria.fr
> https://lists.gforge.inria.fr/mailman/listinfo/frama-c-discuss