fix: float regex on windows

[Alex Romanenko (alextech)]

Got regression on windows (linux works fine).

Float regex caused exception regex_error(error_stack): There was insufficient memory to determine whether the regular expression could match the spec. Researched alternative regex that seems to have same functionality without excessive look-aheads .
Crash can be observed on existing test case: https://github.com/philips-software/amp-cucumber-cpp-runner/blob/external/alextech/testdata/cucumber-expression/matching/matches-bigdecimal.yaml , so no new tests is being added.

Also, while debugging found unused variable. Cleaned it up one time.

If the branch external/alextech can be rebased or recreated with latest changes I can redirect towards it.

[Daan Timmer (daantimmer)]

I need to be 100% sure that this regex has the same functionality as the current regex. As it'll differ from the other implementations:

js: https://github.com/cucumber/cucumber-expressions/blob/76757774a9aa50b1bdb80dff9c9a1711acc3a350/javascript/src/defineDefaultParameterTypes.ts#L5
python: https://github.com/cucumber/cucumber-expressions/blob/76757774a9aa50b1bdb80dff9c9a1711acc3a350/python/src/cucumber_expressions/parameter_type_registry.py#L13-L14
ruby: https://github.com/cucumber/cucumber-expressions/blob/76757774a9aa50b1bdb80dff9c9a1711acc3a350/ruby/lib/cucumber/cucumber_expressions/parameter_type_registry.rb#L12-L13
C#: https://github.com/cucumber/cucumber-expressions/blob/76757774a9aa50b1bdb80dff9c9a1711acc3a350/dotnet/CucumberExpressions/ParameterTypeConstants.cs#L19-L25

[Alex Romanenko (alextech)]

Daan Timmer (@daantimmer) I agree, that moving away from common implementation looks problematic. Though C# too is doing something else entirely. Code that you pointed out generates
(?=.*\d.*)[-+]?(?:\d+(?:[,]?\d+)*)*(?:[.](?=\d.*))?\d*(?:\d+[E]-?\d+)?
which in c++ also happens to crash. Maybe there is a safer c++ library that can handle the original string? Though additional libraries do make repositories heavier.

[Daan Timmer (daantimmer)]

Alex Romanenko (@alextech) what is your exact compiler/SDK version? I am trying to repro locally with the following configuration:

1> [CMake] -- The C compiler identification is MSVC 19.44.35209.0
1> [CMake] -- The CXX compiler identification is MSVC 19.44.35209.0
1> [CMake] -- Detecting C compiler ABI info
1> [CMake] -- Detecting C compiler ABI info - done
1> [CMake] -- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe - skipped
1> [CMake] -- Detecting C compile features
1> [CMake] -- Detecting C compile features - done
1> [CMake] -- Detecting CXX compiler ABI info
1> [CMake] -- Detecting CXX compiler ABI info - done
1> [CMake] -- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe - skipped
1> [CMake] -- Detecting CXX compile features
1> [CMake] -- Detecting CXX compile features - done

And 1> UCRTVersion=10.0.26100.0

I noticed in the <regex> include that there are configuration options:

#define _REGEX_MAX_COMPLEXITY_COUNT 10000000L // set to 0 to disable
#endif // !defined(_REGEX_MAX_COMPLEXITY_COUNT)

#ifndef _REGEX_MAX_STACK_COUNT
#ifdef _WIN64
#define _REGEX_MAX_STACK_COUNT 600L // set to 0 to disable
#else // ^^^ defined(_WIN64) / !defined(_WIN64) vvv
#define _REGEX_MAX_STACK_COUNT 1000L // set to 0 to disable
#endif // ^^^ !defined(_WIN64) ^^^
#endif // !defined(_REGEX_MAX_STACK_COUNT)

Could it be that you have different values here? Or that you have these set in your own project?

Maybe there is a safer c++ library that can handle the original string? Though additional libraries do make repositories heavier.

I've been thinking about exploring the option of adding optional support for google's RE2, as that seems to be the 'better standard'. However, RE2 depends on Abseil. So I might make it an optional dependency that if RE2 is found it will use that and if its not found it'll use std::regex.

But thats an option I haven't explored yet.

[Alex Romanenko (alextech)]

Daan Timmer (@daantimmer)

I am testing on current 2026 visual studio, so MSVC is higher version.

cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_MAKE_PROGRAM=C:/Users/sasha/AppData/Local/Programs/CLion/bin/ninja/win/x64/ninja.exe "-DCMAKE_C_COMPILER=C:/Program Files/Microsoft Visual Studio/18/Community/VC/Tools/MSVC/14.50.35717/bin/Hostx64/x64/cl.exe" -G Ninja -S D:\tmp\cucumber-cpp -B D:\tmp\cucumber-cpp\cmake-build-debug
-- The C compiler identification is MSVC 19.50.35725.0
-- The CXX compiler identification is MSVC 19.50.35725.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/18/Community/VC/Tools/MSVC/14.50.35717/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/18/Community/VC/Tools/MSVC/14.50.35717/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done

I remember this working last year, and git does not show any changes in this area since 12.06.2025 so maybe this is a regression from Microsoft side? But I also remember it working after I ran through my cases on the messages refactoring branch at the end of january and would have noticed this. Unfortunately, cannot remember if I tested on windows or linux on that day.

As for the _REGEX_MAX_COMPLEXITY_COUNT and other parameter, I do not have them set in my project. Also, I always work on reproducing problems in my project on the upstream library test cases. So currently I am unable to run tests even in this repository.
I tried setting just now

#define _REGEX_MAX_COMPLEXITY_COUNT 0
#define _REGEX_MAX_STACK_COUNT 0

in ParameterRegistry.cpp - had no effect :(

[Daan Timmer (daantimmer)]

Alex Romanenko (@alextech) I can repro the issue on my version of MSVC by:

in the top-level CMakeLists.txt

I am still suspecting something to have changed on your end. Perhaps you can try and see//print out the values of these two defines?

[Daan Timmer (daantimmer)]

Alex Romanenko (@alextech) I can confirm there is a regression in MSVC itself: https://godbolt.org/z/81hrGMqPW

I think you might have found a compiler issue. Setting these values to 0 results in a un-catchable hardcrash. Setting them to some very high value results in the exception thrown earlier.

[Alex Romanenko (alextech)]

Daan Timmer (@daantimmer) Exciting. I heard of compiler bugs before, never thought I would see one myself. No point messing with the working function here then. Thank you for the time taken to help verify.

[Daan Timmer (daantimmer)]

Alex Romanenko (@alextech) can I recommend filling a bug at Microsoft? Take my godbolt link as example code and/or provide a minimum viable example project yourself.

I'll also try and get some attention on this on one of the bigger c++ discord communities that happen to have a few MSVC compiler people.

[Alex Romanenko (alextech)]

Daan Timmer (@daantimmer) I am now wondering if it is an STL bug, not a compiler bug. I tried compiling on windows with clang compiler, instead of msvc, (which I could do only after bumping version of gtest to latest commit hash, as the currently specified version has a bug with clang about implicit int conversion and does not compile) and it too crashes. From what I understand, clang uses microsoft STL so perhaps the bug is there in the regex library. Though I could not yet wrangle clang parameters to use libc++ from mingw to verify it works correctly without STL.

There is a suspiciously similar bug microsoft/STL#5792, though it is already closed
And some kind of refactoring around stack handling microsoft/STL#5944

I will need to narrow down to smallest reproducable regex example to make a meaningful bug report.

[Daan Timmer (daantimmer)]

Alex Romanenko (@alextech) you might be correct on that. Although completely wrong, when I say compiler I mean the whole combination or parts of the compiler and or standard library implementation.