Re: [perl #53714] [PATCH] ...further thoughts on proposed fix

Digging a little further into the consequences of null_lib_name.patch,
I see trouble ahead if the new library PMC is cloned into another
interpreter.

The fix lets you create a library PMC with no '_lib_name' property,
but src/dynext.c:Parrot_clone_lib_into assumes that every library
PMC has one.  It causes a 'Null PMC access in get_string()'
exception when it tries to clone the non-existent '_lib_name' prop.

Is there a reason why Parrot_clone_lib_into wants to copy a hard-coded
set of string properties?  What is the intended use of the '_lib_name'
property?  No code in parrot currently touches it except to store
it in new library PMCs and to copy it when cloning them.  Maybe
we should clone it conditionally, just as null_lib_name.patch creates
it conditionally?  Either that, or make sure that every library PMC
always does have a '_lib_name' property.

Tom

• Re: [perl #53714] [PATCH] ...further thoughts on proposed fix by Tom Erdevig