Thank you for the feedback. Before reporting it, I'll wait a bit to see if anyone with access to a later perl release can determine whether still happens there.
Does anyone know a way to suppress this warning while allowing any others to still be displayed? My code trips on several regular expressions, some of which occur inside loops, so I'm getting a lot of noise on the screen. I could have the shell filter stderr, but maybe there's a painless way to control perl warnings with this kind of granularity?
Update: I see that the no warnings 'locale' pragma will silence this warning... but also probably others that I want to see. I reckon there's no way to silence just that specific warning. At least this will get the job done until the underlying bug is fixed.
| [reply]
[d/l] |
The fault can be reduced to the following:
use experimental 'smartmatch';
use POSIX 'locale_h';
use locale ':ctype';
setlocale(LC_CTYPE, 'en_US');
$_ = "x";
utf8::upgrade($_);
/x(y|z)?/;
which gives an assert failure on bleadperl. The locale-variant of the TRIE code in the regex engine appears to be treating the 'no more chars'
special value of nextchr (-10) as a real large utf8 character:
&& UTF8_IS_ABOVE_LATIN1(nextchr)
By all means perlbug it
Dave. | [reply]
[d/l]
[select] |
Thanks, Dave, for the detective work! I confirm that your example produces the warning on v5.22.2 as well. (I'm not quite sure from your description whether the failure method on bleadperl is the same as that on v5.22.2. An assert is a fatal error (in C, anyway), whereas the message I'm seeing does not halt execution; if I add another statement after the end of your code sample, it does get executed.)
I'm happy to submit a bug report, but since you know much more about what's going on under the hood, you're probably a better contact person. If you don't have the time or inclination, however, I'll do it.
| [reply] |
