Ragel has the advantage that CPU blowups happen at compile time, rather than run-time. Other risks aside, they would have avoided this problem had they been using ragel or something similar to pre-compile their patterns into deterministic machines.
What rarely gets discussed in this case was that old, working code was modified in a critical way in order to accommodate new code when that didn't need to be done at all. It was actually a failure in the software development process.
Well doing that would mean ragel would incorrectly read one character, rather than run off forever. Personally I'd rather have the latter. Much easier to catch with memory checkers. Eventually you try to read some thing you're not allowed to read, or blow something else up, instead of just read the first byte of the int following the buffer, or whatever.
There would have to be an additional bounds check when issuing a goto in an error action, but doing that is contrary to the simple execution model that ragel users have come to rely on.
Gotta ask the question, where was the testing when they altered 7 year old code without the involvement of the original developer?
An experienced Ragel programmer would know that when you start setting the EOF pointer you are enabling code paths that never executed before. Like, potentially buggy ones. Eek!
Not at this time. But yes Ragel 7 will make it much easier. The first round of new languages I added helped me polish the technique. Once 7 is out and vetted it will make sense to add more.
Same reason you would want to use yacc to write a parser. A grammar annotated with code is a nice way to express a parser. If the language happens to be regular, you can use ragel to generate a directly executable deterministic state machine. The code is simple and fast.