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: giesl at informatik.rwth-aachen.de (Juergen Giesl)
- Date: Tue, 21 Jan 2014 10:38:49 +0100
- In-reply-to: <08dd7dd2fc25493bba354a41ca92044b@HUB2.rwth-ad.de>
- References: <CAO6+S5r2J-yWZKzjTsVDdWqa93dV8gfgmgLecdLB2iCu69NxVQ@mail.gmail.com> <08dd7dd2fc25493bba354a41ca92044b@HUB2.rwth-ad.de>
Dear Jerry, Try the attached patch, which I apply to the Fedora Linux build of why to > fix this build error. Regards, thanks! We tried it now and indeed, now the tool generates invariants automatically. However, it still can't prove memory safety of easy.c, strlen.c, or strcpy.c. Best Regards Juergen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gforge.inria.fr/pipermail/frama-c-discuss/attachments/20140121/27782b1e/attachment-0001.html>
- 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] Frama-c: WP issues
- Previous by thread: [Frama-c-discuss] Proving Memory Safety of String Algorithms without Providing Loop Invariants
- Next by thread: [Frama-c-discuss] Frama-C: Detecting unreachable code?
- Index(es):