Re: pmc RECALL command for preprocessor

Sure,

the basic problem is that in perlint.pmc we have something like:

void set_string( PMC* value ) {
  CHANGE_TYPE( SELF, PerlString );
  SELF->data = value->data
}

In other words implement a COW strategy after being changed into a
PerlString.  However, in perlstring.pmc
the following is performed:

void set_string( PMC* value ) {
  SELF->data = string_copy( INTERP, value->data );
}

In other words implement an immediate copy strategy.

So, the problem is that PerlInt is changed into a PerlString, but DOESN"T do
what PerlString does
on the SAME function.  Instead, PerlInt should read:

void set_string( PMC* value ) {
  CHANGE_TYPE(pmc, PerlString);
  SELF->vtable->set_string( value );
}

Thereby just recalling the function after changing the type.
In fact, the PerlUndef class did exactly that.

The RECALL command automates that so that set_string now looks like:

void set_string( PMC* value ) {
  CHANGE_TYPE( pmc, PerlString );
  RECALL;
}

will be turned into the correct code shown above.  By
using the RECALL command we get correct semantics
and no copy and paste bugs.

Does that make sense?

Tanton

• pmc RECALL command for preprocessor by Tanton Gibbs
• Re: pmc RECALL command for preprocessor by Leon Brocard
• Re: pmc RECALL command for preprocessor by Tanton Gibbs
• Re: pmc RECALL command for preprocessor by steve
• RE: pmc RECALL command for preprocessor by Brent Dax
• Re: pmc RECALL command for preprocessor by Tanton Gibbs
• Re: pmc RECALL command for preprocessor by Nicholas Clark