in reply to Re^4: [XS] sv_setpv change in behaviour with perl-5.42.0 and later
in thread [XS] sv_setpv change in behaviour with perl-5.42.0 and later

I think this is a matter of semantics. A particular buffer, once allocated, has size SvLEN() and never shrinks. However, that buffer can (under some circumstances) be freed and a different buffer allocated with a smaller SvLEN().

Dave.

  • Comment on Re^5: [XS] sv_setpv change in behaviour with perl-5.42.0 and later

Replies are listed 'Best First'.
Re^6: [XS] sv_setpv change in behaviour with perl-5.42.0 and later
by syphilis (Archbishop) on Jan 30, 2026 at 05:23 UTC
    However, that buffer can (under some circumstances) be freed and a different buffer allocated with a smaller SvLEN().

    Yep - and my first little demo is one that hits one of those "circumstances" when run on perl-5.42.0, but not when run on perl-5.40.0.
    (That's the change in behaviour that bothered me a little.)
    The fact (AFAIK) that it hasn't broken any modules on cpan suggests that this change is not something to be too concerned about.

    And we don't have to invoke XS to demonstrate the change. The following one liner will do that quite well:
    $ perl -MDevel::Peek -le '$x = "x" x 65; Dump $x; $x = "y"; Dump $x;'
    On perl-5.40.0, the Dump() shows that the address associated with $x's "PV" retains it's initial setting, and the value of $x's SvLEN remains at its original value.
    Neither of those 2 things hold on perl-5.42.0, with SvLEN being significantly reduced.

    Thanks guys.

    Cheers,
    Rob

      Yeah, you don't need XS. As I explained, the change was to make "x" x 65 behave the same as "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", and you never used XS for the "x" x 65 part.