Re: RFA: patch to fix gdb/1680

[mec.gnu@mindspring.com (Michael Elizabeth Chastain)]

The problem is not with tcl, but with expect.

I built two stacks of tcl+expect+dejagnu:

  'released stack' -- all the packages from their ftp sites.
  This is what I normally use.

  'sourceware stack' -- the versions from sourceware.
  This is what Jim B normally uses.

Here is a version table:

	    released  sourceware
  tcl       8.4.6     8.4.1 (nearly)
  expect    5.41      5.26 + patches, dated 1998-06-15
  dejagnu   1.4.4     1.4.3 (nearly)

Both TCL and Expect have their own copies of the Henry Spencer regular
expression code ("HSREC" for short).  You can see this coming: "re-usable
code re-used to hell".

When I use the 'released' stack, the regular expressions in question
get interpreted by TCL's copy of HSREC.  This is a modern
R.E. compiler with support for braces like "[abc]{1,2}".  It chokes on:

	".. = {0, 0.25, 0.5, 0.75}.*" \

The TCL 8.4.6 and TCL 8.4.1 versions of HSREC are nearly identical,
(they better be because they are both 8.4.X).  They both choke on this.

However, with the sourceware stack, the TCL 8.4.1 HSREC is not even
used!  Instead, expect 5.26 uses its own HSREC.  This is from 1998,
and does not implement '{1,2}' count modifiers.

So we have to write r.e.'s that work with both versions of HSREC.  We
must be doing this right most of the time, because I don't see huge
ERROR blotches in the files I've sampled from gdb-testers@ .

Another question.  How about all those r.e's in gdb.cp such as:

  # gdb.cp/userdef.exp
  \\$[0-9]* = {x = -2, y = -2}

As Daniel J surmised, the HSREC lexer really does have code to
distinguish between "{0,2}" and "{x=0,y=2}".  I watched this code
getting called:

  case CHR('{'):
    ...
    if (ATEOS() || !iscdigit(*v->now)) {
      NOTE(REG_UBRACES);
      NOTE(REG_UUNSPEC);
      RETV(PLAIN,c);
    } else {
      NOTE(REG_UBOUNDS);
      INTOCON(L_EBND);
      RET('{');
    }

So I predict that this regular expression in i386-sse.exp would work fine
with both T+E+D stacks, because it will fool the lexer:

  ".. = {\[$r\], $r.25, $r.5, $r.75}."

And indeed this code works with both sourceware T+E+D and released T+E+D.
Of course, I don't want to see that code in the actual test script;
that was just a test.

I guess it's my job to write doco on "how to write a test script",
including all these quirks of regular expressions.  Sigh.

And finally, this patch is still approved:

  ".. = \\{$r, $r.25, $r.5, $r.75\\}."

Michael C