Re: libc++ patch for LWG Issue 2232 - dangling reference for regex_iterators

Mon, 17 Feb 2014 14:30:43 -0800

On Feb 14, 2014, at 4:31 PM, David Blaikie <[email protected]> wrote:
On Fri, Feb 14, 2014 at 4:21 PM, Marshall Clow <[email protected]> wrote:
Users can write
        for(sregex_iterator i(s.begin(), s.end(), regex("meow")), end; i != end; ++i)

binding a temporary regex to const regex& and storing a pointer to it.
This will compile silently, triggering undefined behavior at runtime.

Fixing this involves defining constructors for the various regex iterator types from rvalue regexes, and then marking them as “deleted”.
And tests.


Would this break (what I assume is) correct code doing things like:

std::find(sregex_iterator(s.begin(), s.end(), regex("meow")), end, "foo”);

Yes, but while that code is technically “correct”, it’s not useful.

The return value from find is going to be an iterator that “points” into a destructed regex.
As soon as you use it for anything, you’re (hopefully) going to go boom.

The “fix” for this is easy.
regex meow { “meow” };
std::find(sregex_iterator(s.begin(), s.end(), meow), end, "foo”);

Now you can control the lifetime of the regex, and make sure that it doesn’t get destroyed too early.

For those following along at home, the standard issue (which was adopted for C++14) is here:

and a closely related one (also part of the C++14 standard):

Here’s a revised patch that covers both of them.

— Marshall

Attachment: LWG2332-2.patch
Description: Binary data


_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to