RE: [boost] yet another regex partial match bug

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-07-27 14:22:39

John Maddock wrote:
> > ...is demonstrated by the following (debug mode) test:
> >
> > #include "boost/regex.hpp"
> > #include <cassert>
> >
> > int main()
> > {
> >     boost::regex re("a");
> >     boost::cmatch match;
> >     assert(boost::regex_match("", match, re, boost::match_partial));
> > }
> 
> That's not a bug, it's meant to do that, as the docs say:
> 
> "A partial match is one that matched one or more characters 
> at the end of the text input, but did not match all of the regular 
> expression (although it may have done so had more input been 
> available). "
> 
> In this case there are no characters to match and so there is 
> no partial match.

But then it contradicts one of its intended uses:

"Partial matches are typically used when either validating data input
(checking each character as it is entered on the keyboard), .."

How you can use it to validate data input if it doesn't validate the very
initial state of every input - an empty string? 

Just to make the contradiction clear, here's the description of the example
in "Partial matches" section from the docs:

"The following example tests to see whether the text could be a valid credit
card number, as the user presses a key, the character entered would be added
to the string being built up, and passed to is_possible_card_number. If this
returns true then the text could be a valid card number, so the user
interface's OK button would be enabled. If it returns false, then this is
not yet a valid card number, but could be with more input, so the user
interface would disable the OK button. Finally, if the procedure throws an
exception the input could never become a valid number, and the inputted
character must be discarded, and a suitable error indication displayed to
the user."

Well, empty string definitely falls into "this is not yet a valid card
number, but could be with more input" category, but with the current
semantics the procedure will throw an exception when, for example, user
deletes the first (incorrectly) entered character. 

BTW, I don't think that explicitly checking for empty string should do the
trick ;) - I believe the current semantics is flawed and doesn't reflect
user's expectations (which are also supported by the docs).

Aleksey