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] Simplifying branches

  • Subject: [Frama-c-discuss] Simplifying branches
  • From: anne.pacalet at inria.fr (Anne Pacalet)
  • Date: Wed, 17 Aug 2011 17:40:37 +0200
  • In-reply-to: <1313594793.20010.56.camel@coquet>
  • References: <1313591386.20010.50.camel@coquet> <4E4BD3B9.2030304@inria.fr> <1313594793.20010.56.camel@coquet>
Le 17/08/2011 17:26, Daniel Sheridan a ?crit :
> Thanks for the pointer. As I am using sparecode as one of the steps in
> my plugin, I would expect to get this for free.

You are probably right !

> However, I see that
> optim_if is never called in such a way that it interprets constant 1 --
> it only eliminates the if statement if there is no condition, which
> seems to occur if the if statement itself is set to non-visible.

The visibility of the if statement in fact means the visibility
of the condition in this context, not the statements in the branches.

> I see that I could use the functor to get the result that I want. But I
> wonder whether this would be a useful enhancement, either in filter.ml
> or in sparecode?

Yes: [sparecode] should test whether the condition as a known value
(probably using [Db.Value.condition_truth_value]) to tell that the if statement
is invisible. I am wondering if it is a good idea or not to put that test
in [filter] since the "clients" of [filter] might want to keep the 'if',
don't they ?

Maybe you should add a feature request in Frama-C bug tracking system:
http://bts.frama-c.com/
to remind me to do that soon...

Thanks.
-- 
Anne.