Added string.match function to lua stdlib

[svermeulen]

I noticed that the crate lua-patterns already did all the hard work for us here, so this is mostly just adding that. We could do the same for some other string functions as well if this gets approved

[svermeulen]

Alternatively - we could use this library as a starting point and vendor all the code that's useful from it

[kyren]

Neat! I didn't realize a lua patterns crate existed... I can definitely understand the utility of having a useful subset of regular expressions while being orders of magnitude simpler. I also wasn't aware that it was even adopted outside of Lua (like in OpenBSD httpd). Cool!

Buuuuuut..... I don't think I can merge either this patch as is OR vendoring the lua-patterns crate as is, because I think it's... a direct port of the Lua 5.2 C code? The core of the pattern matching engine is basically entirely unsafe Rust.. it's misleading to look at because only functions like add sub and and at literally use the unsafe keyword, but those functions themselves should be marked as unsafe, and if you do that you can see that effectively the entire luapat.rs module becomes unsafe, because it is.

Personally I feel like the raison d'être of piccolo's existence is an experiment about how much I can get away with writing a "real" language runtime with as much memory safe code as possible and reasonable speed. Piccolo already includes unsafe obviously, but it's genuinely not very much, and I want to wait as long as I can before starting to really give up on that goal. Obviously a language runtime with things like a JIT is not going to be provably memory safe in Rust, so depending on how far this project goes, eventually I would have to relent, but even if I were to do that I'd like to keep an option to turn off things that are more risky. I think if you don't care about safety at all, there are MUCH better Lua runtimes, and I think that for a Lua runtime that is specifically attempting to bring confident safety to the table, the string matching library is not a place where unsafe is a good tradeoff.

This is fair if people want to criticize me here, I would understand why. Lua is a very battle tested C codebase, and it's very likely that the patterns code from Lua 5.2 is extremely high quality. The authors of Lua at Pontifical Catholic University of Rio de Janeiro are better programmers than me, and certainly better C programmers than me, but it's not like I'm bringing this up out of nowhere either. PUC-Rio Lua is not a good security boundary, and it frankly never has been. You can see bugs for some of what I'm talking about, but even besides that, properly sandboxing PUC-Rio Lua with its C API is hard. This is not relevant to unsafe string matching code of course, more relevant to the reason for piccolo's existence in the first place.

I don't see (at a glance, at least) any discovered memory unsafety bugs for the pattern matching code on the official Lua bugs page but honestly on the balance I'd rather just rewrite it in safe rust, especially considering the pretty small size of the original. It just seems like a bad place to make a tradeoff like this, for a project such as this one. Sorry!

[kyren]

I'm going to leave this issue open until a replacement for pattern matching is actually added though, just so people see the previous discussion about the lua-patterns crate.

[svermeulen]

Makes complete sense. I appreciate the thoughtfulness put into this project! In my local clone, I've started filling out the rest of the missing parts of the Lua stdlib in piccolo, so will see if any of that work can be contributed back instead.

Thanks for your work on this. There are other lua runtimes but I'm not aware of any that are pure rust and therefore support wasm32-unknown-unknown, and I need wasm for the hobby project I'm using this with.