4 ms·
> CTRE is fine as long as you don't overflow the stack Which is to say CTRE is mostly not fine, if you use it on user-provided strings, regardless of target en
by leni536 1y ago
> CTRE is fine as long as you don't overflow the stack
Which is to say CTRE is mostly not fine, if you use it on user-provided strings, regardless of target environment. It's heavily recursion based, with never spilling to the heap and otherwise no safeguards for memory use/recursion depth.
- boricj 1y agoThe regex which was overflowing the stack was something like this (simplified and from memory): ^http:\/\/([a-z0-9.-]+)\/?:([1-9]|[0-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9][0-9][0-9]|[1-5][0-9][0-9][0-9][0-9]|6[0-4][0-9][0-9][0-9]|65[0-4][0-9][0-9]|655[0-2][0-9]|6553[0-5])$ Once I've given up validating the port number with the regex, it no longer blew up the stack: ^http:\/\/([a-z0-9.-]+)\/?:([1-9][0-9]{0,4})$ I'll admit I haven't done a thorough job of auditing the stack usage afterwards, but not all regexes look like Perl codegolf. For simple, straightforward patterns I don't see any problems using CTRE, but I'd be interested to see some proof to the contrary if you have some.
- leni536 1y agoThe problem can occur in general if there is a greedy match within the regex: https://github.com/hanickadot/compile-time-regular-expressions/issues/30 https://github.com/hanickadot/compile-time-regular-expressio... Although it looks like that this got fixed for simple patterns.