[Bug gdb/33321] [gdb] FAIL: gdb.python/py-color-pagination.exp: type=color: mode=write: color-fill write

[aburgess at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=33321

--- Comment #9 from Andrew Burgess <aburgess at redhat dot com> ---
And indeed, I'm now 99% certain that this is a bug in expect.

>From the expect source code, in expect.c, we find this block:

            Tcl_RegExpGetInfo(re, &info);

            buf = Tcl_NewUnicodeObj (buffer,esPtr->input.use);
            for (i=0;i<=info.nsubs;i++) {
                int start, end;
                Tcl_Obj *val;

                start = info.matches[i].start;
                end = info.matches[i].end-1;
                if (start == -1) continue;

                if (e->indices) {
                    /* start index */
                    sprintf(name,"%d,start",i);
                    sprintf(value,"%d",start);
                    out(name,value);

                    /* end index */
                    sprintf(name,"%d,end",i);
                    sprintf(value,"%d",end);
                    out(name,value);
                }

                                /* string itself */
                sprintf(name,"%d,string",i);
                val = Tcl_GetRange(buf, start, end);


The Tcl_RegExpGetInfo call gets information about the last regexp match.  From
the manual page for Tcl_RegExpGetInfo we learn:

  The start and end values are Unicode character indices relative to the offset
location within objPtr where matching began.
  The start index identifies the first character of the matched subexpression. 
The end index identifies the first character
  after the matched subexpression.  If the subexpression matched the empty
string, then start and end will be equal.  If the
  subexpression did not participate in the match, then start and end will be 
set  to -1.

Notice in the expect code though that 'end' always has 1 subtracted, in this
line 'end = info.matches[i].end-1;', which means for the empty match case, 'end
< start', and if 'start == 0' then 'end < 0'.  The start and end are then
passed to Tcl_GetRange, from its man page we learn:

  Tcl_GetRange returns a newly created value comprised of the characters
between first and last (inclusive) in the value's
  Unicode representation.  If the value's Unicode representation is invalid,
the Unicode representation is regenerated from
  the value's string representation.  If first < 0, then the returned string
starts at the beginning of the value. 
  If last < 0, then the returned string ends at the end of the value.

Notice the last line.  This explains the bug.  When we match an empty string at
the start of the input buffer then the Tcl_RegExpGetInfo call returns 'start ==
end == 0', which expect then changes to 'start == 0 && end == -1', and
Tcl_GetRange then returns the full string.

The man page for Tcl_GetRange doesn't say what happens when 'end < start && end
>= 0', but it appears we just get back the empty string, which is what expect
wants.  Unfortunately, expect seems to be mostly unmaintained these days, but
I've raised a ticket here: https://sourceforge.net/p/expect/patches/26/ which I
believe is the correct place.

I'll rewrite this test to avoid this expect bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.