|Do you know where your variables are?|
Re^4: utf8::upgrade and $1by creamygoodness (Curate)
|on Aug 30, 2009 at 22:42 UTC||Need Help??|
Thanks for the kind words. :)
As a practical matter, I think your recommendations to end users regarding using special variables as arguments are sound advice. The same holds true for variables which are overloaded, tied, and so on. Partly this is because XS modules have options with regards to how they treat arguments, and it's hard to get everything right.
In this case, however, I believe that the problem is both contained and solvable. If I'm right, $1 should never have its SVf_POK flag set -- it will always have SVp_POK set, indicating that it has a valid "private pointer", but never the SVf_POK flag. From sv.h:
The task is thus to identify any such variables within Perl_sv_utf8_upgrade_flags_grow and ensure that the SVf_POK flag is off when the function returns. That can be achieved either by never turning it on in the first place, by turning it off at some point, or by throwing an exception.
It may actually be important to ensure that the flag never gets turned on. It's not clear to me that it's valid to call SvPV_force on $1. Should the attempt trigger a "modification of readonly value" exception?
The questions I would like answers to are,
Based on the answers to those questions, we should be able to come up with the proper incantation -- either at the beginning or near the end of the function -- to ensure that $1 leaves with its SVf_POK flag unset.