Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>> > 242-243 is testing legacy EBCDIC range gap hack, and is probably broken
>> > by "use re 'asciirange'" which made other tests work ;-).
>
>At least one EBCDIC range hack never was in fact implemented, but I
>recently added tests for it: the difference between a range i-j and
>its explicit numeric counterpart. If specified in the first way, it
>should match only letters i and j, NOT the gap characters (this we
>have implemented, have had for quite some time), but if in the second
>way, it should match also the gap characters (this we do not have yet,
>and never had).
Ah, so this isn't new breakage.
pat.t though is running under 'asciirange' - this translates local
code points to ASCII/Unicode, computes the set, and then maps
members back to native. This makes i-j do the right thing, but also
makes the corresponding \xHH do the same. But that is going to be
confusing as [\x89-\x91] (i-j) isn' going to match \x90 as it becomes
a 2-member only set. Perhaps \xHH under 'asciirange' should solicit
a warning? (The reason for making it a pragma was to allow legacy
\xhh ranges to carry on working - but apparently they never did...)
--
Nick Ing-Simmons
