aboutsummaryrefslogtreecommitdiff
path: root/gcc/objc
diff options
context:
space:
mode:
authorJonathan Wakely <jwakely@redhat.com>2022-10-25 13:03:12 +0100
committerJonathan Wakely <jwakely@redhat.com>2022-10-28 15:26:35 +0100
commit988dd22ec6665117e8587389ac85389f1c321c45 (patch)
treeafdf2d0d8b3926d273b08300452e41133fb0d6b5 /gcc/objc
parent95decac3ce8c8c7c5302cd6fac005a10463de165 (diff)
downloadgcc-988dd22ec6665117e8587389ac85389f1c321c45.zip
gcc-988dd22ec6665117e8587389ac85389f1c321c45.tar.gz
gcc-988dd22ec6665117e8587389ac85389f1c321c45.tar.bz2
libstdc++: Fix allocator propagation in regex algorithms [PR107376]
The PR points out that we assume the match_results allocator is default constuctible, which might not be true. We also have a related issue with unwanted propagation from an object that might have an unequal allocator. Ideally we use the same allocator type for _State_info::_M_match_queue but that would be an ABI change now. We should investigate if that can be done without breaking anything, which might be possible because the _Executor object is short-lived and never leaks out of the regex_match, regex_search, and regex_replace algorithms. If we change the mangled name for _Executor then there would be no ODR violations when mixing old and new definitions. This commit does not attempt that. libstdc++-v3/ChangeLog: PR libstdc++/107376 * include/bits/regex_executor.h (_Executor::_Executor): Use same allocator for _M_cur_results and _M_results. * include/bits/regex_executor.tcc (_Executor::_M_main_dispatch): Prevent possibly incorrect allocator propagating to _M_cur_results. * testsuite/28_regex/algorithms/regex_match/107376.cc: New test.
Diffstat (limited to 'gcc/objc')
0 files changed, 0 insertions, 0 deletions