Re: assert at insdel.c:1122
Martin Buchholz <martin(a)xemacs.org> writes:
Lisp backtrace follows:
string-match("\\(\\.\\=\\)" ".")
(not (string-match "\\(\\.\\=\\)" "."))
[...]
This happens for me on more than one platform, with and without mule,
but only if I build with error-checking.
Yoshiki, if you cannot reproduce this, you can get access to my own
workspaces.
I can. And my patch supposed fix the crash but I didn't
apply it while I was in Tokyo. I'd like to apply it after
the discussion is over.
Ben, you are the most knowledgable regexp maintainer here. Can you
take a look at this?
Yoshiki, also make sure that any fix does not involve "hiding" the bug
by changing asserts, etc...
No, it doesn't change asserts. In this case, the assert is
too aggressive. The same routine is called by (looking-at
"\\=") and (string-match "\\=" ""). It you do
string-match,
new string is allocated somewhere outside Lisp buffer. So
you need to check whether you are matching against Lisp
string or Lisp buffer. I first thought adding new argument
is easy and right solution but regex.c provides POSIX
interface and I can't change it. You can create a global
variable but I'm reluctant to introduce new grobal
variables. Global variables makes things more complicated.
If you can't distingush it, then you must not assert because
it is a valid value. It might hide one bug, though. If you
match against Lisp buffer and somehow it does not end up
inside the buffer, it won't hit assert.
So the question is, do you want to create a global variable
or not? Any comments are welcome.
--
Yoshiki Hayashi