On Thu, May 09, 2013 at 03:56:49PM +0100, Nicholas Clark wrote: > 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. Is this good enough for yuz? commit fe02ddb7a070fc75fab3f7c2ed77f31b0dc5fc23 Author: David Mitchell <davem@iabyn.com> AuthorDate: Thu May 9 16:57:56 2013 +0100 Commit: David Mitchell <davem@iabyn.com> CommitDate: Thu May 9 17:05:15 2013 +0100 further tweak SvPV() docs Make it clear that a different pointer may be returned each time. Affected files ... M sv.h Differences ... diff --git a/sv.h b/sv.h index 4bfbf9c..7baef34 100644 --- a/sv.h +++ b/sv.h @@ -1490,11 +1490,13 @@ stringified version becoming C<SvPOK>. Handles 'get' magic. See also C<SvPVx> for a version which guarantees to evaluate sv only once. 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>. +equal to C<SvPVX(sv)>, or that C<SvPVX(sv)> contains valid data, or that +successive calls to C<SvPV(sv)) will return the same pointer value each +time. This is 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>. -- "I do not resent criticism, even when, for the sake of emphasis, it parts for the time with reality". -- Winston Churchill, House of Commons, 22nd Jan 1941.Thread Previous | Thread Next