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] introducing hypothesis with ACSL on sets of array elements witk Frama-C/Value


  • Subject: [Frama-c-discuss] introducing hypothesis with ACSL on sets of array elements witk Frama-C/Value
  • From: boris at yakobowski.org (Boris Yakobowski)
  • Date: Sun, 21 Jul 2013 02:07:33 +0200
  • In-reply-to: <569C6D7D26484241A530B87F45ADE1F80CBD69B6@AOFRWMBXRSC004.resources.atosorigin.local>
  • References: <569C6D7D26484241A530B87F45ADE1F80CBD5C40@AOFRWMBXRSC004.resources.atosorigin.local> <7fzjtlnlvu.fsf@cea.fr> <569C6D7D26484241A530B87F45ADE1F80CBD5FB6@AOFRWMBXRSC004.resources.atosorigin.local> <CABbVA-DnL8p6ResAQMLyJ919ZG-6sf-_zKAR-zDZ4Bf1dAWK1Q@mail.gmail.com> <569C6D7D26484241A530B87F45ADE1F80CBD69B6@AOFRWMBXRSC004.resources.atosorigin.local>

I just noticed that Frama-C's parser accepts t[0..1] < 10 and t[0..1]
> 10 for some mysterious reason. However, 10 > t[0..1] and 10 <
t[0..1] are (correctly) rejected. Both WP and Value choke on the first
form, so I guess the type-checker should be made more agressive,
unless Jessie understands this form?

Regarding the evaluation of \forall within Value, this is something
quite new. For the moment, only quantification on C types are (short,
int.., but not integer) are accepted. Also, given the evaluation
strategy, Value will answer False in very rarely -- basically, only if
the property is false on every possible value (while we would like to
see False as soon as the property is false for at least one value).
The dual problem occurs for \exists.

On Sat, Jul 20, 2013 at 11:19 PM, DUPRAT Stephane
<stephane.duprat at atos.net> wrote:
> Hello Boris,
>
> Thank you for these precisions that are very relevant for me.
> Before your message, writing '0 <= tab2[2..3] <= 10' was not so disturbing for me. And I was not aware of the beginning of evaluating quantifiers in Frama-C/Value,
>
> Regards,
>
> St?phane
>
>
>
> -----Message d'origine-----
> De : frama-c-discuss-bounces at lists.gforge.inria.fr [mailto:frama-c-discuss-bounces at lists.gforge.inria.fr] De la part de Boris Yakobowski
> Envoy? : jeudi 18 juillet 2013 00:03
> ? : Frama-C public discussion
> Objet : Re: [Frama-c-discuss] introducing hypothesis with ACSL on sets of array elements witk Frama-C/Value
>
>
> Hi St?phane,
>
> On Wed, Jul 17, 2013 at 10:14 PM, DUPRAT Stephane <stephane.duprat at atos.net> wrote:
>> It still remains the solution of introducing these hypothesis by a C function calling f1 and performing some initialization in the context. But it is not an ACSL solution.
>
> Sure !  But Matthieu was aiming at an ACSL-only solution.
>
> The amount of development needed in Value to reduce by preconditions/assertions of the form 'tab2[2..3]==23' is non-trivial, but also not completely unreasonable. (Say, of similar complexity to previous medium-sized developments that were done to improve the evaluation of the logic in Value.)
>
> Notice however that 'tab2[2..3]==23' is in fact translated to '{ tab2[2..3] } == {23}', which really means '{ tab2[2] ; tab2[3] } == {23}'. That is, your equality is actually an equality on sets. Thus you cannot write '0 <= tab2[2..3] <= 10', which is meaningless on sets
> -- or at least not lifted point-wise on the elements of the set. In this case, you should use universal quantification, for which a very preliminary form of evaluation has appeared in the development version of Value. Unfortunately, no reduction is currently performed either, only evaluation. Reducing by \forall-quantified predicates would be more interesting and more general than reducing by sets equality, and we could in fact easily translate the latter into the former.
> Unfortunately, it is highly non-trivial if we want to handle predicates more generic than a few hard-coded common cases...
>
> HTH,
>
> _______________________________________________
> Frama-c-discuss mailing list
> Frama-c-discuss at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/frama-c-discuss
> ________________________________
>
>
> Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? du groupe Atos ne pourra ?tre engag?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre engag?e pour tout dommage r?sultant d'un virus transmis.
>
> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.



-- 
Boris