#1255 string match oddity when - is the last char

obsolete: 8.3
open-later
3
2004-10-04
2000-10-26
Anonymous
No

OriginalBugID: 4438 Bug
Version: 8.3
SubmitDate: '2000-03-21'
LastModified: '2000-04-03'
Severity: MED
Status: Assigned
Submitter: techsupp
ChangedBy: hobbs
OS: Windows 95
OSVersion: OSR2
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'

Name:
Keith Lea

ReproducibleScript:
% string match {[a-z0-9_/-]} \\ 1
% string match {[a-z0-9_/]} \\ 0

It's accidently interp'ing the "/-]" as "/-]]", taking last
] as ] endrange and ] endblock.
-- 04/03/2000 hobbs
This needs to be fixed in Tcl_String(Case)Match in tclUtil.c,
but wait until 8.4 just in case someone was counting on the
previous perverse behavior.
-- 04/03/2000 hobbs

Discussion

1 2 > >> (Page 1 of 2)
  • Hmm. The problem seems to be that the first pattern is actually malformed by the rules of [string match], but there is no way to indicate this. I suppose the correct way of dealing with this is to decide that we were not really matching a range after all, but that's not very good at all. Either that, or we state that a malformed pattern matches nothing at all.

    Hmm. On successful matching of a range, should we really back up a character at the unexpected end of string , or should we fail at that point?

     
  • Improved detection of bug:
    % sstring match \[a-] ]
    1
    % string match \[a-]x ]x
    0

     
    • priority: 5 --> 6
     
    • labels: 104238 --> 18. Commands M-Z
     
    • assigned_to: nobody --> dkf
     
  • Apparently, the way [string match] handles syntactically invalid patterns is by failing to match anything at all. It's not entirely clear to me that this is an optimal strategy...

     
  • Logged In: YES
    user_id=79902

    This behaviour won't be changed before 9.0

    Any fixes that *are* done must be applied to code in both tclUtil.c and tclUtf.c

     
    • priority: 6 --> 3
    • status: open --> open-later
     
  • Simon Bachmann
    Simon Bachmann
    2003-11-23

    Logged In: YES
    user_id=915599

    I encountered a problem with `string match' too. I suppouse
    it is, finally, the same bug: it is possible to match a [ in
    a character set quoting int with \. Thits should work with ]
    too, but it doesn't!

    % string match {[\[]} {[}
    1
    % string match {[\]]} {]}
    0

     
1 2 > >> (Page 1 of 2)