diff --git a/README.md b/README.md index 723f4ae..1b86dcf 100644 --- a/README.md +++ b/README.md @@ -86,10 +86,10 @@ There are some caveats to the panic / abort guarantee, however: Yet another goal of the library is to, in all cases, safely handle panics generated by Rust callbacks. Panic unwinds in Rust callbacks should currently be handled correctly -- the unwind is caught and carried across the Lua API -boundary as a regular lua error in a way that prevents Lua from catching it. +boundary as a regular Lua error in a way that prevents Lua from catching it. This is done by overriding the normal Lua 'pcall' and 'xpcall' with custom versions that cannot catch errors that are actually from Rust panics, and by -handling panic errors on the receiving rust side by resuming the panic. +handling panic errors on the receiving Rust side by resuming the panic. In summary, here is a list of `rlua` behaviors that should be considered a bug. If you encounter them, a bug report would be very welcome: @@ -108,10 +108,10 @@ If you encounter them, a bug report would be very welcome: * Lua C API errors are handled by lonjmp. *ALL* instances where the Lua C API would longjmp should be protected from Rust, except in a few cases of internal callbacks where there are only Copy types on the stack. If you - detect that `rlua` is triggering a longjmp over rust stack frames (other + detect that `rlua` is triggering a longjmp over Rust stack frames (other than the internal ones), this is a bug! (NOTE: I believe it is still an - open question whether technically Rust allows longjmp over rust stack frames + open question whether technically Rust allows longjmp over Rust stack frames *at all*, even if there are only Copy types on the stack. Currently `rlua` uses this to avoid having to write a lot of messy C shims. It *currently* works fine, and it is difficult to imagine how it would ever NOT work, but - what is and isn't UB in unsafe rust is not precisely specified.) + what is and isn't UB in unsafe Rust is not precisely specified.)