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] my first frama verification
- Subject: [Frama-c-discuss] my first frama verification
- From: boris at yakobowski.org (Boris Yakobowski)
- Date: Wed, 26 Aug 2015 22:37:06 +0200
- In-reply-to: <55D6D766.9000208@linux-france.org>
- References: <CAGSRWbgk8sbO4DKZ-ij8jbDALBgt8e7K4dAto-puDQZqbu+76Q@mail.gmail.com> <55D6CCA5.901@linux-france.org> <55D6D766.9000208@linux-france.org>
Hi David, With the open-source version, I obtain the same results as Tim (at least until I get bored, and kill the analysis): no initialization warning. On the other hand, I can reproduce your results, including the analysis time, by activating option -val-slevel-merge-after-loop @all. Is this option set by TrustInSoft Analyzer? Given the way Tim's main function is written, this option completely changes the number of separate paths that are analyzed: - with the option set, only one analysis is performed, with an imprecise value for sz, ksz, buf and kbuf. This is due to the merge that occurs at the beginning of each loop, regardless of the number of states that initially enters the loop. - without this option, the two loops that initialize buf and kbuf separate sz and ksz into all possible values, resulting in 64 * 256 different analyses. HTH, On Fri, Aug 21, 2015 at 9:46 AM, David MENTRE <dmentre at linux-france.org> wrote: > Hello Tim, > > Le 21/08/2015 09:00, David MENTRE a écrit : > >> YMMV. I haven't look at your code, but it might appear that your >> specific code indeed needs hours to check due to some very complex >> functions. Or you need optimizations provided by TrustInSoft Analyser >> (for memcpy and the like functions). ;-) >> > > For what is worth, your code is analysed in 1m40s with TrustInSoft > Analyser. > > It found 6 warnings: > bits.c:12:[kernel] warning: accessing uninitialized left-value: assert > \initialized(&byte); > sha2.c:377:[kernel] warning: accessing uninitialized left-value: assert > \initialized(&tmp); > auth.c:32:[kernel] warning: accessing uninitialized left-value: assert > \initialized(x); > frama-driver.c:34:[value] Assertion got status unknown. > auth.c:64:[value] Function auth: precondition got status unknown. > auth.c:93:[value] Assertion got status unknown. > > DISCLAIMER: I did this verification very quickly, so I might have badly > configured Frama-C or missed an obvious error message! > > I join to the email the resulting verification log. I didn't look at > verification result to understand the warnings. > > Best regards, > david > > > _______________________________________________ > Frama-c-discuss mailing list > Frama-c-discuss at lists.gforge.inria.fr > http://lists.gforge.inria.fr/mailman/listinfo/frama-c-discuss > -- Boris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gforge.inria.fr/pipermail/frama-c-discuss/attachments/20150826/681f3fb6/attachment.html>
- Follow-Ups:
- [Frama-c-discuss] my first frama verification
- From: dmentre at linux-france.org (David MENTRE)
- [Frama-c-discuss] my first frama verification
- References:
- [Frama-c-discuss] my first frama verification
- From: tim.newsham at gmail.com (Tim Newsham)
- [Frama-c-discuss] my first frama verification
- From: dmentre at linux-france.org (David MENTRE)
- [Frama-c-discuss] my first frama verification
- From: dmentre at linux-france.org (David MENTRE)
- [Frama-c-discuss] my first frama verification
- Prev by Date: [Frama-c-discuss] specification question
- Next by Date: [Frama-c-discuss] my first frama verification
- Previous by thread: [Frama-c-discuss] my first frama verification
- Next by thread: [Frama-c-discuss] my first frama verification
- Index(es):