From @cpansprout

If we could remove the requirement that PVs in SVs have a terminating null, we could make things like substr() faster (by having it use the same string buffer as the full original string).

Since it is not uncommon in XS code to pass SvPV(...) to a system function that expects null termination, we would probably have to make SvPV allocate a new string with the null, and introduce a new version of SvPV (SvPV_nn_ok(sv,len)?) that may return unterminated strings and assumes the caller will depend solely on the len value.

Of course, any code that passes SvPVX to a C function will probably break. I don’t know whether there is any way to avoid that. A survey of SvPVX uses on CPAN would be time-consuming, but helpful.

--

Father Chrysostomos

From @iabyn

On Mon, May 23, 2016 at 04​:51​:29PM -0700, Father Chrysostomos wrote​:

If we could remove the requirement that PVs in SVs have a terminating
null, we could make things like substr() faster (by having it use the
same string buffer as the full original string).

Since it is not uncommon in XS code to pass SvPV(...) to a system
function that expects null termination, we would probably have to make
SvPV allocate a new string with the null, and introduce a new version of
SvPV (SvPV_nn_ok(sv,len)?) that may return unterminated strings and
assumes the caller will depend solely on the len value.

Of course, any code that passes SvPVX to a C function will probably
break. I don’t know whether there is any way to avoid that. A survey
of SvPVX uses on CPAN would be time-consuming, but helpful.

SvPV* are used 1000+ times in the main *.c perl core. All those uses would
have to be reviewed to see whether the inefficient copying version needs
retaining.

According to http​://grep.cpan.me, excluding ppport.h etc, 163
distributions use SvPV_* and 224 distributions use SvPVX*

That's a lot of breakage, inefficiency, or fixups.

--
The optimist believes that he lives in the best of all possible worlds.
As does the pessimist.

The RT System itself - Status changed from 'new' to 'open'

From @cpansprout

On Tue Jun 21 08​:44​:13 2016, davem wrote​:

On Mon, May 23, 2016 at 04​:51​:29PM -0700, Father Chrysostomos wrote​:

If we could remove the requirement that PVs in SVs have a terminating
null, we could make things like substr() faster (by having it use the
same string buffer as the full original string).

Since it is not uncommon in XS code to pass SvPV(...) to a system
function that expects null termination, we would probably have to make
SvPV allocate a new string with the null, and introduce a new version of
SvPV (SvPV_nn_ok(sv,len)?) that may return unterminated strings and
assumes the caller will depend solely on the len value.

Of course, any code that passes SvPVX to a C function will probably
break. I don’t know whether there is any way to avoid that. A survey
of SvPVX uses on CPAN would be time-consuming, but helpful.

SvPV* are used 1000+ times in the main *.c perl core. All those uses would
have to be reviewed to see whether the inefficient copying version needs
retaining.

According to http​://grep.cpan.me, excluding ppport.h etc, 163
distributions use SvPV_* and 224 distributions use SvPVX*

That's a lot of breakage, inefficiency, or fixups.

So it’s probably less useful than making the stack hold reference counts. :-)

--

Father Chrysostomos