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] Getting a node from its id for a particular pdg
- Subject: [Frama-c-discuss] Getting a node from its id for a particular pdg
- From: Pascal.Cuoq at cea.fr (Pascal Cuoq)
- Date: Fri, 20 Mar 2009 10:49:38 +0100
- In-reply-to: <1237402185.3508.226.camel@supelec>
- References: <1237387890.3508.114.camel@supelec> <49C116F4.5050507@sophia.inria.fr> <1237402185.3508.226.camel@supelec>
> > > That's why I want to assume a 'worst case scenario' and add all the > statements that statement 2 depends on to the dependencies of > statement > 4. (because Db.Pdg.all_dpds stops at the OutRet and InCtrl nodes of > statement 2) Two remarks : 1/ To reiterate what Anne was saying, it doesn't make sense to use different assumptions for the different computations that are taking place (i.e. the value analysis and the PDG). Using a worst case scenario for the library function at the time of exploiting the PDG is a bad idea because the value analysis already made some assumptions, that may have been more optimistic, about the library function, and the PDG uses the results of the value analysis (and therefore depends on its assumptions) everywhere else in the analyzed program. The right way is to have every plug-in agree on the same specification for the library function. If the default specification generated for a library function when none is present is not to your liking, and if it's not practical for you to write specifications for all the library functions in your analysis project, please tell us how these specifications should have been generated automatically and we will see what we can do. 2/ The real worst-case scenario is when your library function overwrites every global in memory -- actually, any reachable cell. Needless to say, the value analysis can not possibly say anything interesting after the call if it has to assume this. What exactly do you mean by "worst-case scenario"? Considering the dependencies that you would like to get, it seems that you mean that the library function may access any reachable cell but not write any. Is that it? Regards, Pascal
- References:
- [Frama-c-discuss] Getting a node from its id for a particular pdg
- From: jcdemay at rennes.supelec.fr (Jonathan-Christofer Demay)
- [Frama-c-discuss] Getting a node from its id for a particular pdg
- From: anne.pacalet at sophia.inria.fr (Anne Pacalet)
- [Frama-c-discuss] Getting a node from its id for a particular pdg
- From: jcdemay at rennes.supelec.fr (Jonathan-Christofer Demay)
- [Frama-c-discuss] Getting a node from its id for a particular pdg
- Prev by Date: [Frama-c-discuss] Getting a node from its id for a particular pdg
- Next by Date: [Frama-c-discuss] Verifying recursive functions
- Previous by thread: [Frama-c-discuss] Getting a node from its id for a particular pdg
- Next by thread: [Frama-c-discuss] Getting a node from its id for a particular pdg
- Index(es):