Branch: refs/heads/yves/fix_19350
Home: https://github.com/Perl/perl5
Commit: b6dcc2d197cdf4ff77baa9123f4fdb13046cabb6
https://github.com/Perl/perl5/commit/b6dcc2d197cdf4ff77baa9123f4fdb13046cabb6
Author: Yves Orton <[email protected]>
Date: 2022-01-23 (Sun, 23 Jan 2022)
Changed paths:
M op.c
Log Message:
-----------
Issue #19350: Revert op.c change from 2a98b8cbbc6f75b
This reverts the op.c change from
"newSVpvn_flags().. is more efficient than sv_2mortal(newSVpvn(..))"
full commit id 2a98b8cbbc6f75b5aaefb10acc4da4427359fcea
For some reason the op.c change tickles a compiler bug. Various minor
changes to the text result in this working as expected, and then other
changes make it fail, etc. I was not able to work out why, the code as
presented is not wrong, although it hides some stuff underneath.
The expression is:
newSVpvn_flags( PadnamePV(name)+1,PadnameLEN(name)-1,
(PadnameUTF8(name)) ? SVf_UTF8|SVs_TEMP : SVs_TEMP
);
Which should be the same as:
sv_2mortal(newSVpvn_utf8(
PadnamePV(name)+1,PadnameLEN(name)-1, PadnameUTF8(name)
));
However for some reason the compiler does something different. An
interesting subtlety is that PadnameUTF8() always returns 1. So you
would think that it could be replaced by
newSVpvn_flags( PadnamePV(name)+1,PadnameLEN(name)-1, SVf_UTF8|SVs_TEMP);
but when I compile that it seems to randomly produce the right result or
not. I tried various formulations of parenthesizing the arguments,
reducing the ternary to its natural result (above) etc, and the compiler
seemed to produce random results. The only formulation that reliably
produced the correct results is the original one.
