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] [Jessie] Issue with behavior in contracts
- Subject: [Frama-c-discuss] [Jessie] Issue with behavior in contracts
- From: nshmyrev at yandex.ru (Nickolay V. Shmyrev)
- Date: Wed, 04 Mar 2009 19:25:12 +0300
- In-reply-to: <49AE6ACF.7020604@inria.fr>
- References: <3d13dcfc0903030830m26d0d328n1ac6057eed4a1ff8@mail.gmail.com> <3d13dcfc0903040242g6ed73581g2a4789408a2d27b9@mail.gmail.com> <49AE6ACF.7020604@inria.fr>
04.03.09, 14:49, "Claude March?" <Claude.Marche at inria.fr>: > David MENTRE wrote: > > Hello, > > > > On Tue, Mar 3, 2009 at 17:30, David MENTRE <dmentre at linux-france.org> wrote: > >> I would like to define the behaviour of read() syscall. I'm using the > >> following contract: > >> /*@ requires fd >= 0; > >> requires count > 0; > >> requires \valid((char*)buf+(0..count-1)); > >> behavior error: > >> assigns global_error_number; > >> ensures \result < 0; > >> behavior end_of_file: > >> assigns \nothing; > >> ensures \result == 0; > >> behavior normal: > >> assigns ((char*)buf)[0..count-1]; > >> ensures ((char*)buf)[0] >= 0 && ((char*)buf)[0] < 256; > >> ensures \result > 0; > >> */ > Even worse: since you have no assumes clauses in your behaviors, then > your specification says that at return, the \result is both < 0, == 0 > and >0. This is clearly wrong Hello. I wanted to share some of my thoughts about this. I was also confused by behaviour in the past btw, it's not very suitable word for case separation, "case" would be more familar to C developer. And the more confusing thing is --jessie-behaviour option that from the first point of view allows to analyze some orthogonal aspect of specification without touching others. For example behaviour memory: requires valid(a); behariour safety requires a[0] > 1; So that during analysis you only need to prove the obligations that work with memory or only safety statements. Now I suspect it doesn't work this way. But it would be nice to have something like that.
- References:
- [Frama-c-discuss] [Jessie] Issue with behavior in contracts
- From: dmentre at linux-france.org (David MENTRE)
- [Frama-c-discuss] [Jessie] Issue with behavior in contracts
- From: dmentre at linux-france.org (David MENTRE)
- [Frama-c-discuss] [Jessie] Issue with behavior in contracts
- From: Claude.Marche at inria.fr (Claude Marché)
- [Frama-c-discuss] [Jessie] Issue with behavior in contracts
- Prev by Date: [Frama-c-discuss] [Jessie] Issue with behavior in contracts
- Next by Date: [Frama-c-discuss] Issue with modulo over unsigned int
- Previous by thread: [Frama-c-discuss] [Jessie] Issue with behavior in contracts
- Next by thread: [Frama-c-discuss] [Jessie] Issue with behavior in contracts
- Index(es):