Re: regexp match violates string bound

#0 fixup_search_regs_for_string () at search.c:279 #1 string_match_1 () at search.c:418 #2 Fstring_match () at search.c:435 as of revision 1.17.2.7 of that file. The value to be assigned there is obtained by traversing string data up to byte `search_regs.end[i]', requiring all the data to be in mule internal coding. Preceding text shows the meaning of "incorrect" in that phrase. And certainly "inconsistent" is cleaner. Except explicit "decoding from mule internal coding" [1] of data that are not in it, is there "illegal" elisp code that is allowed to crash? As to the code above, it is irrelevant. The trouble is not error signalled to / by elisp interpreter, but mule internal coding data traversal failure. It occurs during computations that are done always and set values that may or may not be requested later by elisp through `match-string' call. It makes the entire xemacs process non-functional, that is, crashes it, just as any other mule internal coding traversal failure do. That is, whether the traversal fails always depends on (potentially random) memory contents. If built with `--error-checking' arg including `typecheck', it manifests as assertion failure. Otherwise, depending on memory contents, it may be memory (read) access violation or infinite loop. Footnotes. [1] Implemented `#ifdef DEBUG_XEMACS' in 21.5. Why not in 21.4 do not know. Why should it be worse than FSF that implements it by default?