Front page | perl.perl5.porters |
Postings from May 2013
On Thu, May 09, 2013 at 03:52:15PM +0100, Dave Mitchell wrote: > On Mon, May 06, 2013 at 03:59:20PM +0100, Dave Mitchell wrote: > > Perhaps we just need to clarify SvPV and rely on the fact that all the > > others say "SvPVfoo is just like SvPV, except for foo". > > In the absence of any feedback, I've applied the following commit: Sorry, I'm one of about 600 people guilty of this. > @@ -852,8 +852,8 @@ Set the actual length of the string which is in the SV. See C<SvIV_set>. > =for apidoc Am|U32|SvUTF8|SV* sv > Returns a U32 value indicating the UTF-8 status of an SV. If things are set-up > properly, this indicates whether or not the SV contains UTF-8 encoded data. > -Call this after SvPV() in case any call to string overloading updates the > -internal flag. > +You should use this I<after> a call to SvPV() or one of its variants, in > +case any call to string overloading updates the internal flag. Thanks for stressing this further. > +Note that there is no guarantee that the return value of C<SvPV()> is > +equal to C<SvPVX(sv)> (or even that C<SvPVX(sv)> contains valid data), due > +to the way that things like overloading and Copy-On-Write are handled. In > +these cases, the return value may point to a temporary buffer or similar. > +If you absolutely need the SvPVX field to be valid (for example, if you > +intend to write to it), then see L</SvPV_force>. This also looks useful. Is there a good way to add (without clutter) the possibility that the implication of this is that repeated calls to SvPV() on the same scalar might each produce a pointer to a different buffer? That has caught out some code before, including in the core. Nicholas ClarkThread Previous | Thread Next