tammela added a comment. > I'm not sure what you mean by that. Can you elaborate?
Sure, it's was just a nod to your previous comment about that running callbacks (C++ lambdas) inside a `pcall` is a dangerous API. Although possible, it requires that the developer be very cautious about implicit throws. > The way I see it, the problem is not about which environment is the c++ code > running in, as it can't throw an exception (in llvm). The problem is what > happens when we call lua from c++, and the lua code throws. And this is a > problem regardless of the environment the C(++) code is in -- the difference > is "only" in whether lua will panic or jump over the C code, but something > bad will happen anyway. I agree 100% with your analysis of the problem. > I think that could be solved by ensuring we always call lua in a protected > environment. That way lua will never unwind through the C code (regardless of > what environment it is in) because it would always stop right at the boundary. > > That would essentially mean, lua_call is banned (except maybe as an > optimization, if you can be sure that the code you're about to call will not > throw), and all C->lua transitions should go through lua_pcall. And we can > provide a wrapper that handles catches those errors and converts them to > llvm::Error/Expected, similar to how the python things do it. I have posted a redesign based on your comments. The `lua_push*` functions are all safe-ish. The Lua implementation guarantees at least 20 stack slots when the `lua_State` is created so I've added the stack checks for sanity rather than necessity. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91508/new/ https://reviews.llvm.org/D91508 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
