[Bug libstdc++/89927] Inconsistent behavior in std::regex when optimized

[Bug libstdc++/89927] Inconsistent behavior in std::regex when optimized

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89927

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #2)
> Right, the program is using std::regex incorrectly, and has undefined
> behaviour.
> 
> Compiling with -D_GLIBCXX_ASSERTIONS will cause the program to abort at
> runtime:
> 
> /home/jwakely/gcc/8/include/c++/8.3.1/bits/regex_scanner.tcc:189: void
> std::__detail::_Scanner<_CharT>::_M_scan_normal() [with _CharT = char]:
> Assertion 'false' failed.
> Aborted (core dumped)

That assertion no longer fails, because since I fixed PR 84110 the null zero at
the end of the input string no longer reaches that assertion. Instead we just
walk off the end of the string, and keep going until we reach the address of
the second string literal.

I'm not sure how to detect this reliably. I don't think we can, without some
new GCC object size checking builtins to check if two pointers are both part of
the same object.

With -fsanitize=address you will get an error at runtime.

The assertion that no longer fails could still be clarified though.

[Bug libstdc++/89927] Inconsistent behavior in std::regex when optimized

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89927

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:6b6788f8c2748060d922cc22173ff7f8500917e9

commit r12-4326-g6b6788f8c2748060d922cc22173ff7f8500917e9
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Mon Oct 11 12:08:59 2021 +0100

    libstdc++: Add valid range assertions to std::basic_regex [PR89927]

    This adds some debug assertions to basic_regex. They don't actually
    diagnose the error in the PR yet, but I have another patch to make them
    more effective.

    Also change the __glibcxx_assert(false) consistency checks to include a
    string literal that tells the user a bit more about why the process
    aborted. We could consider adding a __glibcxx_bug or
    __glibcxx_internal_error macro for this purpose, but ideally we'll never
    hit such bugs anyway so it shouldn't be needed.

    libstdc++-v3/ChangeLog:

            PR libstdc++/89927
            * include/bits/regex.h (basic_regex(const _Ch_type*, size_t)):
            Add __glibcxx_requires_string_len assertion.
            (basic_regex::assign(InputIterator, InputIterator)): Add
            __glibcxx_requires_valid_range assertion.
            * include/bits/regex_scanner.tcc (_Scanner::_M_advance())
            (_Scanner::_M_scan_normal()): Use string literal in assertions.

[Bug libstdc++/89927] Inconsistent behavior in std::regex when optimized

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89927

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Closing as fixed for GCC 12