>>>> "Sean" == Sean MacLennan
Sean> Can you, or anybody else, come up with a case that causes
Sean> [lack of AT_STRINGS_END(d)] to fail?
Not easily. We don't "own" the next byte after the end of the
string. To get it to crash depends on the implementation of malloc,
as would getting it to behave incorrectly. But that's exactly why the
post-patch code is wrong, because it accesses something after the end
of the string.
Sean> No, because the not case is simplier.
It's _not_ simpler. It's exactly the same, except that you reverse
the sense of the return value. If this doesn't work something is
seriously wrong; you'll break the algebraic laws that regexps obey.
Have you looked at my patch at all? (BTW, I committed it to 21.5 last
night, with Ben's blessings. ;-)
Sean> The problem with \b is that currently it is too
Sean> permissive. If we are at the start or end we automatically
Sean> (string-match "\\B" " ") fails, which we expect.
Huh? There are no word boundaries in the target string; it should
match at 0.
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.