🚀 go-pugleaf

Consider the following regular expression:

	\(foo\(bar\)\|second\)\2

matching the string "second".  When the \2 is matched, regend[2] will
still contain (unsigned char *) -1 when it is used by the duplicate:
branch of re_match_2.  I can think of three solutions:

  1.  Have re_compile_pattern reject this usage.  (Probably hard to
      detect reliably.)

  2.  Test for this case in the duplicate: branch and goto fail.
      (I.e., an orphan \2 always fails to match.)

  3.  Test for this case in the duplicate: branch and break.
      (I.e., an orphan \2 matches the null string.)

The second alternative would allow a nifty "programming trick":

	\(one\(\)\|two\(\)\)-and-\(three\2\|four\3\)

would match only "one-and-three" or "two-and-four".  Of course
this is most useful when the "-and-" part is actually something
big and ugly.

Caveat:  This is all just from perusing the source.  On my HP-UX
machine, the above string-match operation returns "nil" without
crashing.  But I think that's just because HP-UX happens to map
memory at address -1.  My apologies if this bug is already being
avoided by some subtlety that I was too obtuse to see!

--------

A semi-related request:

The example use of store-match-data in the manual, protecting
the match data around a body of code, fails to work around a
string match if any of the markers being saved are at position
zero.

If match-data returned integers instead of markers when the
associated match was in a string, and store-match-data accepted
these integers, this would not be a problem.

In fact, providing a built-in "with-saved-match-data" construct
would probably encourage safe practices among lazy Lisp programmers!
Also, why doesn't store-match-data itself do the validation illustrated
in the restore-match-data example in the manual?

Thanks,
								-- Dave