Good point. The number of times is zero. Probably something that should be implemented defensively at the library level. I guess most developers don't realise this can happen (I did not).
Good point. The number of times is zero. Probably something that should be implemented defensively at the library level. I guess most developers don't realise this can happen (I did not).
I actually did add a timer as a final "if all else fails" for my regex implementation rather recently, maybe 6 months ago. I don't even know of any scenario that could reach the timer because I have a robust allowlist/denylist and a ton of unit tests. But I would rather just be certain and it wasn't hard.
No you don't actually want a regex library that randomly fails when someone runs one of Chris Domas's pathological stall instructions on a different core.
Why do you say "randomly fails"? Do you consider a configurable timeout with an exception to be a random failure?
Yes. It will fail whenever something else in the system steals your CPU time. Calling code definitely isn't checking for errors either.
What do you want it to do under those conditions then? Stall pathologically?
Yes? If someone locks up the CPU for 60 seconds while your regex library is running, it should take 60 seconds longer to give the same result.
Why would you use wall clock time for this?