Skip to content

Commit 8824a23

Browse files
committed
Remove slightly triggering, and now misleading, language from README
1 parent a49ea51 commit 8824a23

File tree

1 file changed

+3
-10
lines changed

1 file changed

+3
-10
lines changed

README.md

+3-10
Original file line numberDiff line numberDiff line change
@@ -115,13 +115,6 @@ If you encounter them, a bug report would be very welcome:
115115
*absolutely* a bug, particularly because without `LUA_USE_APICHECK` it would
116116
generally be unsafe.
117117
* Lua C API errors are handled by lonjmp. *ALL* instances where the Lua C API
118-
would longjmp should be protected from Rust, except in a few cases of
119-
internal callbacks where there are only Copy types on the stack. If you
120-
detect that `rlua` is triggering a longjmp over Rust stack frames (other
121-
than the internal ones where this is intentional), this is a bug! (NOTE: I
122-
believe it is still an open question whether technically Rust allows longjmp
123-
over Rust stack frames *at all*, even if there are only Copy types on the
124-
stack. Currently `rlua` uses this to avoid having to write a lot of messy C
125-
shims. It *currently* works fine, and it is difficult to imagine how it
126-
would ever NOT work, but what is and isn't UB in unsafe Rust is not
127-
precisely specified.)
118+
would longjmp should be protected from Rust, except in internal callbacks
119+
where this is intentional. If you detect that `rlua` is triggering a
120+
longjmp over your Rust stack frames, this is a bug!

0 commit comments

Comments
 (0)