This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Handling stack overflow in <regex>
- From: Tim Shen <timshen at google dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Date: Wed, 19 Aug 2015 22:08:34 -0700
- Subject: Re: Handling stack overflow in <regex>
- Authentication-results: sourceware.org; auth=none
- References: <CAG4ZjN=+yQqBbXSBq4UbUeZhWe5WoosKGgjT=_YEzma27oc-XQ at mail dot gmail dot com> <20150819091412 dot GM27791 at redhat dot com>
On Wed, Aug 19, 2015 at 2:14 AM, Jonathan Wakely <jwakely@redhat.com> wrote:
> I have no idea how plausible it is, but it sounds complicated.
I wrote an example for illustration:
https://github.com/innocentim/StackOverflowException
In this example, we created a new stack and run Bar on this stack.
Since we know the size of this stack, we can explicitly and
periodically check for overflow. Unlike -fsplit-stack, which is
exclusive, this check is done only in regex code by looking at
__builtin_frame_address(0), and is completely hidden from the user.
The context creation/switching code will also be used by stackful
coroutines (stackless coroutines may require slightly different
version). So those architecture dependent code is not specific for
regex, but will be anyway implemented when someone is implementing
coroutine in the future. You may pretend that we live in the future
and regex is implemented in terms of free allocated stack :)
> Weren't you just going to use a dynamically-allocated container
> instead of recursive function calls?
I were, but I think this approach utilized more existing (or coming)
feature to reduce regex's own complexity. I prefer the recursive way
mainly because of readability and performance (checking frame register
is cheaper than manually pushing and poping a stack).
I'm not 100% sure this is the best way to go though, since the
non-recursive way is "safer"; but that's simply boring and not
innovative :/
By the way, what's the current status of standardizing coroutine and
implementing in GCC? Sometimes I just don't understand their workflow.
:P
--
Regards,
Tim Shen