Usually if the string passed to g_regex_match*() matches as far as
it goes, but is too short to match the entire pattern, FALSE is
returned. There are circumstances where it might be helpful to
distinguish this case from other cases in which there is no match.
Consider, for example, an application where a human is required to
type in data for a field with specific formatting requirements. An
example might be a date in the form ddmmmyy, defined by the pattern
"^\d?\d(jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec)\d\d$".
If the application sees the user’s keystrokes one by one, and can
check that what has been typed so far is potentially valid, it is
able to raise an error as soon as a mistake is made.
GRegex supports the concept of partial matching by means of the
G_REGEX_MATCH_PARTIAL flag. When this is set the return code for
g_regex_match() or g_regex_match_full() is, as usual, TRUE
for a complete match, FALSE otherwise. But, when these functions
return FALSE, you can check if the match was partial calling
g_match_info_is_partial_match().
When using partial matching you cannot use g_match_info_fetch*().
Because of the way certain internal optimizations are implemented
the partial matching algorithm cannot be used with all patterns.
So repeated single characters such as "a{2,4}" and repeated single
meta-sequences such as "\d+" are not permitted if the maximum number
of occurrences is greater than one. Optional items such as "\d?"
(where the maximum is one) are permitted. Quantifiers with any values
are permitted after parentheses, so the invalid examples above can be
coded thus "(a){2,4}" and "(\d)+". If G_REGEX_MATCH_PARTIAL is set
for a pattern that does not conform to the restrictions, matching
functions return an error.
Since 2.14
Usually if the string passed to g_regex_match*() matches as far as it goes, but is too short to match the entire pattern, FALSE is returned. There are circumstances where it might be helpful to distinguish this case from other cases in which there is no match. Consider, for example, an application where a human is required to type in data for a field with specific formatting requirements. An example might be a date in the form ddmmmyy, defined by the pattern "^\d?\d(jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec)\d\d$". If the application sees the user’s keystrokes one by one, and can check that what has been typed so far is potentially valid, it is able to raise an error as soon as a mistake is made. GRegex supports the concept of partial matching by means of the G_REGEX_MATCH_PARTIAL flag. When this is set the return code for g_regex_match() or g_regex_match_full() is, as usual, TRUE for a complete match, FALSE otherwise. But, when these functions return FALSE, you can check if the match was partial calling g_match_info_is_partial_match(). When using partial matching you cannot use g_match_info_fetch*(). Because of the way certain internal optimizations are implemented the partial matching algorithm cannot be used with all patterns. So repeated single characters such as "a{2,4}" and repeated single meta-sequences such as "\d+" are not permitted if the maximum number of occurrences is greater than one. Optional items such as "\d?" (where the maximum is one) are permitted. Quantifiers with any values are permitted after parentheses, so the invalid examples above can be coded thus "(a){2,4}" and "(\d)+". If G_REGEX_MATCH_PARTIAL is set for a pattern that does not conform to the restrictions, matching functions return an error. Since 2.14