https://svn.boost.org/trac10/ticket/12619 <p> Boost.Regex is a great library that we use extensively. I am re-raising Ticket 11776 as a bug. The <code>partial_match</code> implementation is broken because regex repetitions (*, +) may behave lazy or greedy depending on input text buffer size. This is very unfortunate, because <code>partial_match</code> provides the <strong>only</strong> possible mechanism to search streaming input text without buffering the entire text. To restrict the regex to simple forms that do not include repetitions (*, +) is not a viable workaround. There are use cases in which we must take interactive input (i.e. buffering one char at a time) or take large files in which the pattern searched may not fit in the current buffer allocated, thus not producing the longest match, and worse we don't know if the buffer must be enlarged to continue iterating to find the longest match. </p> <p> The correct <code>partial_match</code> algorithm should consider that <strong>as long as backtracking on a repetition pattern in the regex is still possible given some partial input text, Boost.Regex should flag the result as a partial match instead of a full match.</strong>. With this change, matching "<code>abc.*123</code>" may require the whole input, but in this case that is OK! We need this flexibility of the matcher with a buffering approach. </p> <p> Unfortunately, the suggested workaround by the Boost.Regex documentation to check if the pattern matched the input up to the buffer end (which indicates a partial match) does not always work. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/12619 Trac 1.4.3 Dr. Robert van Engelen <engelen@…> Wed, 23 Nov 2016 17:16:31 GMT https://svn.boost.org/trac10/ticket/12619 https://svn.boost.org/trac10/ticket/12619 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">boostbug.cpp</span> </li> </ul> <p> Small example to demonstrate the issue </p> Ticket