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] Dead code that shouldn't be
- Subject: [Frama-c-discuss] Dead code that shouldn't be
- From: jcdemay at rennes.supelec.fr (Jonathan-Christofer Demay)
- Date: Wed, 18 Mar 2009 16:16:05 +0100
Hi, I'm back with this problem. I managed to patch nullhttpd so that I could perform the analysis I wanted to. Now, I want to use frama-c to analyse something way bigger than nullhttpd, so I was wondering if it would be possible (and if it was any relevant) to tell frama-c to ignore those probable run-time errors and continue the analysis ? Thanks. On Wed, 2008-12-12 at 03:25 +0100, Pascal Cuoq wrote: > This is what happens when a missing bit of context makes the > analyzer believe that a run-time error certainly happens quickly. > ... > One way to locate the instruction where it wrongly thinks that > a run-time error certainly happens is to follow the control flow > until the first dead statement in the gui.
- Follow-Ups:
- [Frama-c-discuss] Dead code that shouldn't be
- From: pascal.cuoq at cea.fr (Pascal Cuoq)
- [Frama-c-discuss] Dead code that shouldn't be
- Prev by Date: [Frama-c-discuss] Getting a node from its id for a particular pdg
- Next by Date: [Frama-c-discuss] Unability to verify an arithmetic assertion disapears in a reduced but similar test case
- Previous by thread: [Frama-c-discuss] Getting a node from its id for a particular pdg
- Next by thread: [Frama-c-discuss] Dead code that shouldn't be
- Index(es):