On Sunday 31 August 2008 14:04:53 [EMAIL PROTECTED] wrote:
> +PARROT_API
> +void
> +Parrot_pcc_invoke_sub_from_sig_object(PARROT_INTERP, ARGIN(PMC *sub_obj),
> + ARGIN(PMC *sig_obj))
> +{
> +#define PCC_ARG_MAX 1024
> + /* variables from PCCINVOKE impl in PCCMETHOD.pm */
> + /* args INSP, returns INSP */
> + INTVAL n_regs_used[] = { 0, 0, 0, 0, 0, 0, 0, 0 };
> +
> + /* Each of these is 8K. Do we want 16K on the stack? */
> + opcode_t arg_indexes[PCC_ARG_MAX];
> + opcode_t result_indexes[PCC_ARG_MAX];
> +
> + const char *signature = string_to_cstring(interp,
> VTABLE_get_string(interp, sig_obj));
I skimmed this function in some detail and believe that signature leaks;
certainly it leaks at the first few exception calls.
> + VTABLE void mark() {
> + Parrot_CPointer * const data = PARROT_CPOINTER(SELF);
> +
> + if (data->sig)
> + pobject_lives(interp, (PObj *)data->sig);
> +
> + if (string_equal(interp, data->sig, CONST_STRING(interp, "P")) ==
> 0) { + PMC **pmc_pointer = (PMC **) data->pointer;
> + pobject_lives(interp, (PObj *) *pmc_pointer);
> + }
> + else if (string_equal(interp, data->sig, CONST_STRING(interp,
> "S")) == 0) { + STRING **str_pointer = (STRING **)
> data->pointer;
> + pobject_lives(interp, (PObj *) *str_pointer);
> + }
> + }
I look at this and think "You know, if we don't want to subclass this PMC for
the different types of pointers it can store and morph appropriately, we
could keep variant vtable entries for the different types and swap the vtable
depending on whether it stores a PMC or a STRING." Then I think "That's
exactly the kind of evil we could use to fix the madness in the Key PMC."
Then I think "Hey, is it midnight already?"
That doesn't make my idea bad.
-- c
