Stephen J. Turnbull writes:
Doesn't mean we shouldn't try to approximate it. If you can
new tests, please don't hesitate to suggest them. (BTW, have you
signed, or would you be willing to sign an FSF assignment, for tests?
It would be a shame, Martin's theories on test suites not
withstanding, if we didn't eventually contribute this to GNU
That whole approach is wrong, IMHO, because it makes verifying the
code twice as hard. At least, I can come up with no conditions where
\B != not \b when that code is reached. Thus you only have to check
one. With your method, all test cases need to be checked on both
paths since they use different code to handle them.
Ok, agreed. I will remove the if from the notwordbound case. This was
more of an optimization than a necessity.
Furthermore, your patch probably introduces a crash, because you
indeed can "fall off the end" of a Lisp string. There's no guarantee
that &string + length(string) is in the data segment, let alone that
it is '\000'. (In fact, allowing NUL bytes in strings is one of the
reasons why Lisp doesn't use the C representation for strings.) So
you _must_ check for AT_STRINGS_END(d) in both cases.
Can you, or anybody else, come up with a case that causes it to fail?
I have been trying and can't get it to fail, or is it something that
"will work most of the time but will fail sometimes"? Or is
string-match just to restricted to show the failure?
Finally, I suspect that \B will fail the corresponding tests using
your patch. You've just "moved the bug" into the other branch of
No, because the not case is simplier. The problem with \b is that
currently it is too permissive. If we are at the start or end we
automatically pass. This is what causes (string-match "\\b" " ")
problems. We are at the start of the string, so we pass. With no other
qualifiers, we are done. However the opposite is not
true. (string-match "\\B" " ") fails, which we expect.