On Sat, Jun 28, 2014 at 2:48 AM, Jonathan Wakely jwak...@redhat.com wrote:
OK for trunk, thanks.
Committed.
Thanks!
--
Regards,
Tim Shen
On 27/06/14 09:53 -0700, Tim Shen wrote:
On Fri, Jun 27, 2014 at 12:37 AM, Paolo Carlini
paolo.carl...@oracle.com wrote:
The actual patch is missing.. ;)
Sigh...every time. Sorry.
PS: sorry for being distracted by other issues: what happened to the other
regex issue? I think we are simply
On Sat, Jun 28, 2014 at 2:48 AM, Jonathan Wakely jwak...@redhat.com wrote:
I wonder if it would be better to use a sorted
vectorpair_StateIdT,_StateIdT instead of a map, for improved
memory footprint and runtime speed, but that can be changed later.
In this case, we keep inserting (__m[__u] =
Hi,
On 06/27/2014 05:56 AM, Tim Shen wrote:
The limit can be customized by defining a macro
_GLIBCXX_REGEX_STATE_LIMIT. The default value is 10.
The testcase can be handled if we optimize consecutive quantifiers
(collapse them to one). But cases like (a{100}b){100} can't be
handled still.
On Fri, Jun 27, 2014 at 12:37 AM, Paolo Carlini
paolo.carl...@oracle.com wrote:
The actual patch is missing.. ;)
Sigh...every time. Sorry.
PS: sorry for being distracted by other issues: what happened to the other
regex issue? I think we are simply going to apply, when ready, your more
Hi,
On 06/27/2014 06:53 PM, Tim Shen wrote:
PS: sorry for being distracted by other issues: what happened to the other
regex issue? I think we are simply going to apply, when ready, your more
complete fix, right?
The problem given in the other PR (PR 61582) is also solved by this
patch (but I
The limit can be customized by defining a macro
_GLIBCXX_REGEX_STATE_LIMIT. The default value is 10.
The testcase can be handled if we optimize consecutive quantifiers
(collapse them to one). But cases like (a{100}b){100} can't be
handled still.
We implement range quantifier (foo){n} by
