Front page | perl.perl5.porters |
Postings from June 2013
On Fri, May 17, 2013 at 4:14 PM, Dave Mitchell <davem@iabyn.com> wrote:
> 2) If you want to *modify* the string value of an SV by writing into its
> string buffer (for example if you wanted to implement an in-place version
> of the ucfirst() function), then you need to first call SvPV_force (or one
> of its variants like SvPV_force_nomg, SvPVutf8_force etc). This will
> coerce the SV into a PV-compatible type regardless of its previous
> contents (or croak with "Can't coerce HASH to string" or similar, if it's
> something not convertible).
>
> Note that this may destroy the original content of the SV. For example if
> the SV was a reference, then after the call to SvPV(), it's no longer
> a reference, and is instead a plain SvPOK string with a value like
> "ARRAY(0x12345678)"
>
> After modifying the buffer, you will need to do SvSETMAGIC for the
> changes to potentially take effect (for example if the variable is
> tied).
>
> As a shortcut, if you've already done any get magic processing that was
> required, and if the SV is SvPOK, then its okay to use SvCUR and to
> directly read from and write to the SvPVX buffer, and to use SvGROW()
> if you want to write beyond the end of the string. You'll still need
> to call SvSETMAGIC afterwards.
My use-case is related but now quite the same.
I want to get rid of the current buffer to replace it with my own (in
a set-magic callback that checks if perl threw away the buffer I
attached to the SV, and if so reinstate it).
Currently, I'm doing something like:
SV_CHECK_THINKFIRST_COW_DROP(sv),
if(SvROK(sv))
sv_unref_flags(sv, SV_IMMEDIATE_UNREF);
if(SvPOK(sv))
SvPV_free(sv)
I do think that's a valid, if unusual, use-case.
Leon
Thread Previous
|
Thread Next