<regex>: Should regex_match() use the match_results allocator?

[StephanTLavavej]

trafficstars

Reported by https://stackoverflow.com/questions/58399158/use-custom-allocator-for-stdregex-match .

Calling regex_match() or regex_search() with a match_results containing a custom allocator ends up constructing ordinary vector containers in _Matcher, specifically:

https://github.com/microsoft/STL/blob/6aa3b02fde6f885581279ff28d7a6b4f3e38fcb7/stl/inc/regex#L1650-L1652

The Standard is silent on this topic, but libc++ uses the match_results allocator here.

It may be possible to fix this while preserving ABI, by renaming _Matcher (which is a large but internal helper class).

Note: <regex> mostly ignores the existence of allocators; see LWG-1396 "regex should support allocators" and LWG-2216 "regex_replace(basic_string) allocator handling" for examples.

[DJLink]

Hi,

Ok so apologies if this probably has nothing to do with this, but I'm posting because I feel it could somehow be related.

I'm working on a project that has global new /free operator overloads. Recently regex_match() was added, and now this causes a crash on exit. After a bit of searching, and from what I could understand, regex_match internally we will now use our allocator via global new etc. However if seems that facets template somehow only deletes some things much later on when terminating program? Now it tries to delete but custom allocator is already gone and crash.

So the question really is, would allowing a custom allocator to match_results somehow work for this, in this case actually forcing a std::malloc use so it can safely free whenever it chooses to? or any other way to do this. Again sorry if this is not related.

Thanks.

[muellerj2]

I have a draft fix for #5365, but the layout of _Loop_vals_t must be changed for it to be reasonably efficient. This means I will have to rename _Matcher (and _Loop_vals_t obviously) to preserve ABI. Should I include this issue's proposed change at this opportunity as well?

[StephanTLavavej]

@muellerj2 I am somewhat uncomfortable from a risk perspective with the idea of chaining together two significant changes into a single mega-fix, especially when the Standard doesn't speak clearly about this one. Could you make your change pave the way for this potential change, without actually combining them? I'm thinking you could do something like template your _Matcher2 (or whatever name) on an allocator type, but always use it with std::allocator in your PR. That would then make it possible for a later change to use it with a different allocator type, which would be ABI-safe because different specializations don't conflict.