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] Help with -wp-init-const and static evaluation of constants
- Subject: [Frama-c-discuss] Help with -wp-init-const and static evaluation of constants
- From: virgile.prevosto at m4x.org (Virgile Prevosto)
- Date: Thu, 18 Jul 2019 18:14:16 +0200
- In-reply-to: <82be3036-b7b6-a753-8047-b7c325d7585e@proteancode.com>
- References: <c5309feb-8597-c141-6dd2-48da2b49e048@proteancode.com> <CA+yPOVjhCvkoyLc1y1y+35cPX-e_P=-4pqyG8FQb=cxp9zZS8w@mail.gmail.com> <82be3036-b7b6-a753-8047-b7c325d7585e@proteancode.com>
Hello, Le jeu. 18 juil. 2019 à 10:59, Roderick Chapman <rod at proteancode.com> a écrit : > On 18/07/2019 07:14, Virgile Prevosto wrote: > > //@ assert c1 == 300; > > at the beginning of the function and everything gets proved. > > That seems to work, but is unacceptable - the whole point of having named > constants (especially a set of them where the values depend on each other) > is to avoid having literal "magic numbers" all over the place. > Many thanks for this valuable feedback. My point has never been to pretend that this was a perfect solution, only that, to the best of my knowledge, this is the only sensible workaround that can be used with the current version of Frama-C[1]. The second part of my answer hinted at what could be a longer term solution, but this requires an extension of the Frama-C kernel. As always, such an extension may or may not materialize in the next release depending on how well it aligns with the overall objectives of the projects that fund the development of the platform (and/or on the willingness of external contributor(s) to work on that). [1] As a matter of fact, it is also possible to use some kind of lemma function to do the same trick. It still forces you to rewrite a 300 somewhere, but only once and can be kept close to the definition of c1: #include <stddef.h> static const size_t c1 = 300; /*@ ghost /@ assigns \nothing; ensures c1 == 300; @/ void g() {} */ static const size_t c2 = c1 + 1; size_t f (size_t y) { //@ ghost g(); size_t tmp2 = (y / c2); return tmp2; } Best regards, -- E tutto per oggi, a la prossima volta Virgile -------------- section suivante -------------- Une pièce jointe HTML a été nettoyée... URL: <http://lists.gforge.inria.fr/pipermail/frama-c-discuss/attachments/20190718/803fb325/attachment.html>
- References:
- [Frama-c-discuss] Help with -wp-init-const and static evaluation of constants
- From: rod at proteancode.com (Roderick Chapman)
- [Frama-c-discuss] Help with -wp-init-const and static evaluation of constants
- From: virgile.prevosto at m4x.org (Virgile Prevosto)
- [Frama-c-discuss] Help with -wp-init-const and static evaluation of constants
- From: rod at proteancode.com (Roderick Chapman)
- [Frama-c-discuss] Help with -wp-init-const and static evaluation of constants
- Prev by Date: [Frama-c-discuss] Warnings for call to memcpy()... why?
- Next by Date: [Frama-c-discuss] Warnings for call to memcpy()... why?
- Previous by thread: [Frama-c-discuss] Help with -wp-init-const and static evaluation of constants
- Next by thread: [Frama-c-discuss] Why does a string literal not satisfy valid_read_string?
- Index(es):