Front page | perl.perl5.porters |
Postings from January 2013
On Tue, Jan 15, 2013 at 01:24:29PM -0800, bulk88 wrote: > I recently found a bug in a core module, where a loop was done over a > string from SvPVutf8(sv, len) to SvEND(sv). The sv is a RO literal SV. > So it looped over uninitialized memory and sometimes segvs. > > http://perl5.git.perl.org/perl.git/blob/a8c6ff7b8e8c6037333c21f9b3f6b38b9278df4f:/sv.c#l3060 > > A mortal copy was made of the RO SV was made and returned as the result > of SvPVutf8. > > All that SvPVutf8's docs say is "Like C<SvPV>, but converts sv to utf8 > first if necessary." > > SvPV says "The SV may cache the stringified version becoming C<SvPOK>." > So that is the disclaimer that SvPVX after SvPV is not the same pointer > as returned from SvPV. I think the docs can be improved for SvPVutf8 and > maybe SvPV to make it more obvious that these 2 do not create POK SVs. I > don't have any proposed wording so no patch is included. > > This ticket might be related to > http://perl5.git.perl.org/perl.git/commit/fe46cbda823c09f80e4bc48dd93fafb26cc805f6 > and https://rt.perl.org/rt3/Ticket/Display.html?id=108994 . Perhaps: Like C<SvPV>, but returns always returns a utf8 string. char* SvPVutf8(SV* sv, STRLEN len) This may return a pointer to a temporary instead of C<SvPVX(sv)>. The other SvPVutf8* macros should be updated too. TonyThread Previous | Thread Next