[FlopCpp] Crash/Security issue in FlopC++

[Gaetano Mendola]

On Sun, Feb 28, 2010 at 2:47 PM, Tim Hultberg <Tim.Hultberg at eumetsat.int> wrote:
> Hi Gaetano,
>  your quick fix looks good, however if somebody wants something like
>
> void crash() {
>  {
>    MP_model myFirstModel(new OsiCbcSolverInterface);
>    {
>      MP_model myModel(new OsiCbcSolverInterface);
>    }
>    {
>      MP_constraint myConstraint;
>    }
>  }
> }
>
> I guess they would expect myConstraint to be added to myFirstModel, not the default model.
Looks like current_model should really be a stack of models (with
default model at the bottom).

Hi Tim,
I'm almost ready to send you the patch that will threat MP_model(s)
life cycle as a stack
in order to satisfy your example:

void crash() {
     MP_model myFirstModel(new OsiCbcSolverInterface);
     {
      MP_model myModel(new OsiCbcSolverInterface);
    }
    {
      MP_constraint myConstraint;
    }
}

however if the MP_model is allocated on the heap then it can be
destroyed just after a MP_Constraint on the
same scope:

void crash() {
     MP_model*  myFirstModel = new MP_model(new OsiCbcSolverInterface);
     MP_constraint myConstraint;
     delete myFirstModel;
}

in this case the Model on the DTOR has to notify all "his" constraint
that the M member is not valid
anymore. We can disallow the "operator new" in order to avoid MP_model
in the heap *or* notify all
constraints that their "M" is not valid anymore.

MP_model has also two add:

void add(MP_constraint* constraint);   //private
void add(MP_constraint& constraint);  //public

and different semantics, this just breaks the minimum surprise
principle and it's at same time
error prone. May I change the name of the private one?

All those problems arise just to have the "feature" to relief the user
to add a constraint to a model on
his own, this is a typical case of a "minor feature" with an huge
impact on the implementation. Do we
need to keep this feature at all cost ?

Regards
Gaetano Mendola

-- 
cpp-today.blogspot.com