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] Inductive definition of reachability in array-implemented list.
- Subject: [Frama-c-discuss] Inductive definition of reachability in array-implemented list.
- From: eric.jenn at fr.thalesgroup.com (JENN Eric)
- Date: Sun, 07 Jun 2009 15:53:34 +0200
- In-reply-to: <5EFD4D7AC6265F4D9D3A849CEA9219191AB1D7@LAXA.intra.cea.fr>
- References: <4A28B8BD.5080509@fr.thalesgroup.com><4A290576.5010102@fr.thalesgroup.com><4A293B6E.7010806@insa-lyon.fr> <20090605181021.0b3c566f@is005115> <5EFD4D7AC6265F4D9D3A849CEA9219191AB1D7@LAXA.intra.cea.fr>
Dear Pascal Dear All, First, thanks a lot to all of you for taking time to answer. Things are getting clearer... In your last mail, you raise an interesting point about the how abstract interpretation and formal proof may be complementary to some extent. More generally, do you have any hint about how one should use the value analysis plugin AND Jessie to conduct a verification to be as efficient as possible? For instance, would it be possible to generate assertions by means of value analysis and back annotate the code before using Jessie? (Even better, could the results of value analysis be used as some kind of "axioms" (I mean something that does not need to be proved but that can be taken as granted)? Thanks a lot for your time. Regards, e. CUOQ Pascal a ?crit : >>> if not : same player play again, but without exact option. >>> >>> I don't know how to verify this second point. >>> >> If you have a complete application, the value analyzer can take care of >> that: it will emit an alarm each time it can't ensure that no overflow >> occurs. >> > > The value analysis *could* take care of that and emit an alarm > each time it can't ensure that no overflow occurs. Currently, > it assumes that all overflows are desired overflows that are part > of the program's logic, and it continues the analysis with a > correct superset of the values that can actually be obtained > at run-time, assuming 2's complement arithmetic and proper > configuration of the characteristics of the target architecture. > > Pascal > -------------- next part -------------- A non-text attachment was scrubbed... Name: eric.jenn.vcf Type: text/x-vcard Size: 191 bytes Desc: not available Url : http://lists.gforge.inria.fr/pipermail/frama-c-discuss/attachments/20090607/afcc9a9f/attachment.vcf
- Follow-Ups:
- [Frama-c-discuss] Inductive definition of reachability in array-implemented list.
- From: guillaume.melquiond at inria.fr (Guillaume Melquiond)
- [Frama-c-discuss] Inductive definition of reachability in array-implemented list.
- References:
- [Frama-c-discuss] Inductive definition of reachability in an array-implemented list.
- From: eric.jenn at fr.thalesgroup.com (JENN Eric)
- [Frama-c-discuss] Inductive definition of reachability in an array-implemented list.
- From: nicolas.stouls at insa-lyon.fr (Nicolas Stouls)
- [Frama-c-discuss] Inductive definition of reachability in an array-implemented list.
- From: virgile.prevosto at cea.fr (Virgile Prevosto)
- [Frama-c-discuss] Inductive definition of reachability in an array-implemented list.
- From: Pascal.CUOQ at cea.fr (CUOQ Pascal)
- [Frama-c-discuss] Inductive definition of reachability in an array-implemented list.
- Prev by Date: [Frama-c-discuss] Inductive definition of reachability in an array-implemented list.
- Next by Date: [Frama-c-discuss] Array elements passed as reference
- Previous by thread: [Frama-c-discuss] Inductive definition of reachability in an array-implemented list.
- Next by thread: [Frama-c-discuss] Inductive definition of reachability in array-implemented list.
- Index(es):