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] Problem with predicate and location labels
- Subject: [Frama-c-discuss] Problem with predicate and location labels
- From: hollas at informatik.htw-dresden.de (Boris Hollas)
- Date: Mon, 21 Feb 2011 14:49:03 +0100 (CET)
On Mon, 2011-02-21 at 10:27 +0100, Virgile Prevosto wrote: Le ven. 18 f?vr. 2011 15:28:58 CET, > "Boris Hollas" <hollas at informatik.htw-dresden.de> a ?crit : > > > > > The following code verifies, but the specification > > unchanged{P,H}(\at(&this->a, P)); is quite clumsy. > > > > OK, I see your point now. You're right, &this->a does not necessitate a > memory state: it's merely a matter of adding the offset of field 'a' to > 'this'. In fact, I guess that it can be argued that taking the address > of any left value does not require a memory state: this address won't > change for the lifetime of the variable. > However, if predicates indeed use call-by value semantics, shouldn't frama-c interpret &this->a as a value that does not depend on a memory state, hence a label wouldn't be necessary? -- Regards, Boris
- Prev by Date: [Frama-c-discuss] Ghost variables and function prototypes
- Next by Date: [Frama-c-discuss] There may be a problem with the Program Dependence Graph
- Previous by thread: [Frama-c-discuss] Problem with predicate and location labels
- Next by thread: [Frama-c-discuss] Inout analysis question
- Index(es):