I'm not really in favor of this. boost::regex is just the predecessor of std::regex so going back to boost::regex seems like a step back. We'd be pulling in an external dependency for something that's already provided by the standard library.

BTW what string sizes are we talking about here?

Depends on the platform's default stacksize limit but on x86_64-linux this leads to reliable crashes: #3804

Looks like this may get fixed upstream: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164#c8

I'm not really in favor of this. boost::regex is just the predecessor of std::regex so going back to boost::regex seems like a step back. We'd be pulling in an external dependency for something that's already provided by the standard library.

BTW what string sizes are we talking about here?

It does not really increase the closure size though in Nix. There might be some distributions such as Debian that package liboost_regex separately: https://packages.debian.org/sid/amd64/libboost-regex1.71-dev/filelist

What is your proposed fix instead? fixing libstdc++'s regex is beyond my capabilities.

Looks like this may get fixed upstream: gcc.gnu.org/bugzilla/show_bug.cgi?id=86164#c8

Not really the commenter gave up.

I'm not really in favor of this. boost::regex is just the predecessor of std::regex so going back to boost::regex seems like a step back. We'd be pulling in an external dependency for something that's already provided by the standard library.

BTW what string sizes are we talking about here?

28k in my case.

Note that libboost_regex.so is about 1.3 MB, but worse, it pulls in libicu4c which is 34 MB.

I think it used regcomp before: b05b98d#diff-52d20285486e90d564ca2535d4d0fe55L11

It could be reverted to that. However its too much guessing from my side what the maintainers actually want as a acceptable solution so I just leave it as it is given that the one bug in nixpkgs itself is fixed...

+1 for PCRE, oniguruma or any other regexp engine that has a consistent evaluation across platforms.

@zimbatm While I would absolutely love PCRE the problem is that Nix is already using POSIX ERE and migrating to something else would break builtins.match.