Branch: refs/heads/yves/fix_19350
Home: https://github.com/Perl/perl5
Commit: 38a7a787ae132eee05e0490bf486d84158582ea0
https://github.com/Perl/perl5/commit/38a7a787ae132eee05e0490bf486d84158582ea0
Author: Yves Orton <[email protected]>
Date: 2022-01-23 (Sun, 23 Jan 2022)
Changed paths:
M t/re/pat_advanced.t
Log Message:
-----------
Test for Issue #19250, assert fail with Debug=>ALL
Commit: 735d71ed8a4e6a1e6dc1f7a7505dbf55b27aebb2
https://github.com/Perl/perl5/commit/735d71ed8a4e6a1e6dc1f7a7505dbf55b27aebb2
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.
Compare: https://github.com/Perl/perl5/compare/b6dcc2d197cd...735d71ed8a4e