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] Proving Memory Safety of String Algorithms without Providing Loop Invariants
- Subject: [Frama-c-discuss] Proving Memory Safety of String Algorithms without Providing Loop Invariants
- From: loganjerry at gmail.com (Jerry James)
- Date: Mon, 20 Jan 2014 09:08:27 -0700
- In-reply-to: <CAO6+S5r2J-yWZKzjTsVDdWqa93dV8gfgmgLecdLB2iCu69NxVQ@mail.gmail.com>
- References: <CAO6+S5r2J-yWZKzjTsVDdWqa93dV8gfgmgLecdLB2iCu69NxVQ@mail.gmail.com>
On Mon, Jan 20, 2014 at 8:10 AM, Juergen Giesl < giesl at informatik.rwth-aachen.de> wrote: > We would like to let Frama-C generate loop invariants by itself. To this > end, we also installed apron 0.9.10. We tried to compile Why (including > Jessie) with the option --enable-apron which would in turn allow us to > start Jessie with the option -jessie-infer-annot. But unfortunately, we did > not manage to compile Why with this option. The output of the compiler is > attached in why.err. Indeed, Yannick Moy told us that the code for loop > invariant generation was most likely removed from Why2. > Try the attached patch, which I apply to the Fedora Linux build of why to fix this build error. Regards, -- Jerry James http://www.jamezone.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gforge.inria.fr/pipermail/frama-c-discuss/attachments/20140120/0b42c74b/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: why-2.33-hashtbl.patch Type: text/x-patch Size: 2169 bytes Desc: not available URL: <http://lists.gforge.inria.fr/pipermail/frama-c-discuss/attachments/20140120/0b42c74b/attachment.bin>
- References:
- [Frama-c-discuss] Proving Memory Safety of String Algorithms without Providing Loop Invariants
- From: giesl at informatik.rwth-aachen.de (Juergen Giesl)
- [Frama-c-discuss] Proving Memory Safety of String Algorithms without Providing Loop Invariants
- Prev by Date: [Frama-c-discuss] Proving Memory Safety of String Algorithms without Providing Loop Invariants
- Next by Date: [Frama-c-discuss] Proving Memory Safety of String Algorithms without Providing Loop Invariants
- Previous by thread: [Frama-c-discuss] Proving Memory Safety of String Algorithms without Providing Loop Invariants
- Next by thread: [Frama-c-discuss] Proving Memory Safety of String Algorithms without Providing Loop Invariants
- Index(es):