Bug #14367
Wrong interpretation of backslash C in regexp literals
Status:
Open
Priority:
Normal
Assignee:
-
Target version:
-
ruby -v:
ruby 2.6.0dev (2018-01-16 trunk 61875) [x86_64-darwin15]
Tags:
Description
Following ruby code returns nil.
% LC_ALL=C ruby -ve 'p(/\c\xFF/ =~ "\c\xFF")'
ruby 2.6.0dev (2018-01-16 trunk 61875) [x86_64-darwin15]
nil
Is this intentional?
Updated by Hanmac (Hans Mackowiak) about 3 years ago
the problem is this:
/\c\xFF/.source == "\\c\\xFF"
which is already escaped
you might want this:
/#{"\c\xFF"}/ == /ƒ/
or use this:
Regexp.compile("\c\xFF")
PS: it is correct that i get this?
"\c\xFF" == "\x9F" #=> true
EDIT: this works
/\x9F/ =~ "\c\xFF" #=> 0
Updated by shyouhei (Shyouhei Urabe) about 3 years ago
Hanmac (Hans Mackowiak) wrote:
the problem is this:
/\c\xFF/.source == "\\c\\xFF"
No, I believe that isn't the problem. For instance /\c\x7F/ works.
% LC_ALL=C ruby -ve 'p(/\c\x7F/ =~ "\c\x7F")'
ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin15]
0
EDIT: this works
/\x9F/ =~ "\c\xFF" #=> 0
Yeah, that's why I titled this issue a "wrong interpretation of backslash C in regexp literals". This is about /...\c.../
.
Updated by shyouhei (Shyouhei Urabe) 10 months ago
Can I have any answer for my question ("Is this intentional?")?
Updated by naruse (Yui NARUSE) 10 months ago
It looks inconsistency handling between regexp and Ruby's for \c\xff
:
% LC_ALL=C ruby -ve 'p (/\c\xff/ =~ "\x1f")' ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-darwin18] 0