This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
toke.c: Refactor part of tr// handling, mostly for EBCDIC
authorKarl Williamson <khw@cpan.org>
Thu, 19 Jan 2017 04:48:51 +0000 (21:48 -0700)
committerKarl Williamson <khw@cpan.org>
Thu, 19 Jan 2017 21:42:08 +0000 (14:42 -0700)
commit5ca37d54d00c488ab61212700339a9a1db3441a8
tree4cff6a7586662bba19b49b3bc2dc25767cf86a6b
parentaca416674931e15d761081a4bf7403619de2f0de
toke.c: Refactor part of tr// handling, mostly for EBCDIC

Commit af9be36c89322d2469f27b3c98c20c32044697fe changed toke.c to count
the number of UTF-8 variant characters seen in a string so far.  If the
count is 0 when the string has to be upgraded to UTF-8, then only a flag
has to be flipped, saving reparse time.  Incrementing this count wasn't
getting done during the expansion of ranges like A-Z under tr///.  This
currently doesn't matter for ASCII platforms, as the count is currently
treated as a boolen, and it was getting set if a range endpoint is
variant.  On EBCDIC platforms a range may contain variants even if both
endpoints are not.  For example \x00-\xFF.  (\xFF is a control that is
an invariant).  This led to a lot of noise on an EBCDIC smoke, but no
actual tests failing.

I want to keep it as a count so that in the future, things could be
changed so that count can be used to know how big to grow a string when
it is converted to UTF-8, without having to re-parse it as we do now.
It turns out that we need to have this count anyway in the tr/// code as
that grows the string to account for the expansion, and needs to know
how many variants there are in order to do so if the string already is
in UTF-8.  So refactoring that code slightly allows the count to served
double-duty, for the grow if it is already UTF-8, and how much to grow
if it isn't UTF-8.  And it fixes the noise problem on EBCDIC
toke.c