News for hackers. Stuff that matters.

A comment on Building Fast Interpreters in Rust. Parent comment

Re:Building Fast Interpreters in Rust by kstenerud on Monday March 04, 2019 @12:58PM (#19303474)
This is how ragel [1] does things. It basically compiles to giant-switch state machines, and is damn fast.

[1] https://www.colm.net/open-source/ragel/

[ Parent | on HN ]
Re:Building Fast Interpreters in Rust by nicoburns on Monday March 04, 2019 @10:10PM (#19307794)
Ragel was also the source of cloudbleed! So I would definitely understand if cloudflare were wary of using that kind of technique again.
[ Parent | on HN ]
Re:Building Fast Interpreters in Rust by jgrahamc on Tuesday March 05, 2019 @04:10AM (#19309237)
That's not the right way to talk about it. The error was in code that used Ragel but it was all on us. But as part of improving things we have moved away from non-memory safe languages and Ragel was using C.
[ Parent | on HN ]
Re:Building Fast Interpreters in Rust by nicoburns on Tuesday March 05, 2019 @06:45AM (#19309882)
Ah, I had thought it was a bug in the code generated by ragel. But I guess not!
[ Parent | on HN ]
Re:Building Fast Interpreters in Rust by jgrahamc on Tuesday March 05, 2019 @11:38AM (#19311731)
In a way it was, but it wasn't Ragel's fault. We made an error that ended up with generated C code that contained the bug. Bottom line for us was... use memory safe languages.
[ Parent | on HN ]
Re:Building Fast Interpreters in Rust by Matthias247 on Monday March 04, 2019 @10:27PM (#19307863)
As far as I remember not Ragel was the issue, but the code around it. If you use a Rust parser from inside broken C code which Leaks memory the same thing can happen.
[ Parent | on HN ]
Re:Building Fast Interpreters in Rust by jgrahamc on Monday March 04, 2019 @03:35PM (#19305116)
Agreed. We used to use Ragel for some tasks and it was fast.
[ Parent | on HN ]