Frama-C-discuss mailing list archives

This page gathers the archives of the old Frama-C-discuss archives, that was hosted by Inria's gforge before its demise at the end of 2020. To search for mails newer than September 2020, please visit the page of the new mailing list on Renater.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Frama-c-discuss] [Value analysis] Validating a function with behavior spec.

  • Subject: [Frama-c-discuss] [Value analysis] Validating a function with behavior spec.
  • From: pascal.cuoq at gmail.com (Pascal Cuoq)
  • Date: Fri, 13 Apr 2012 11:21:29 +0200
  • In-reply-to: <4F87EDF3.7080608@adacore.com>
  • References: <CAFaEDLCHYJtescjnsqs6gE5q_Nx5+CWSg_3AD=f9pN_AHhq4=w@mail.gmail.com> <CAOH62JgyUC8+2cHf-bsPmVnWcL+JxyV88mnVo9gHc0j5Ym=JqQ@mail.gmail.com> <4F87EDF3.7080608@adacore.com>
> Pascal, just to satisfy my curiosity, what is causing imprecisions in the
> value analysis in the code:
>
>
> ? ? ? ? ? ? ? ?retval = (uint8)val;
> ? ? ? ? ? ? ? ?/*@ assert retval == val; */
>
>
> Is it the cast which is treated as an unknown function?

The value analysis wouldn't work as a C interpreter on Csmith-generated
programs if it did not know how to handle casts such as (unit8), because
there are a lot of those in Csmith-generated programs
(http://blog.frama-c.com/index.php?post/2011/08/29/CompCert-gets-a-safe-interpreter-mode
)

The imprecise operation here is == between non-singleton sets of
values. val can be 1 or 2, and retval can be 1 or 2, therefore the
equality may be true but cannot be guaranteed to be so.

Boris Yakobowski has more to say about the provability of the assertions in the
original example. I will let him make that other point.

Pascal