Closed fstirlitz closed 6 years ago
Lua strings are bytestrings, and the language doesn't prescribe any particular encoding for them (Lua 5.3 adds \u{} escapes which expand to UTF-8 code units, but this is a purely syntactic convenience). This binding, however, expects all strings to be UTF-8 and doesn't allow passing or receiving arbitrary byte sequences between Rust code and Lua code.
There's a AnyLuaString
struct that you can read if you want a non-UTF8 String: https://github.com/tomaka/hlua/blob/f889c8af6e7f51279de9e80dc7a60a7114c8cf79/hlua/src/any.rs#L13
Furthermore, this imposition of arbitrary semantics was done in a particularly sloppy way: the code below will panic instead of just returning an Err(_) value (which happens for e.g. mismatched types).
That's a bug.
Actually that one's fixed too...
Well, my bad. In my defence, it wasn't released yet.
On the other hand, the code still cuts the string at any embedded zero byte. Should have used slice::from_raw_parts
instead of CStr
. And I don't see the Push
trait implemented for &[u8]
or Vec<u8>
, like it is for &str
and String
.
And I don't see the Push trait implemented for &[u8] or Vec
, like it is for &str and String.
That would push an array of integers and not a string. The reason why AnyLuaString
exists is to not have this ambiguity.
Lua strings are bytestrings, and the language doesn't prescribe any particular encoding for them (Lua 5.3 adds
\u{}
escapes which expand to UTF-8 code units, but this is a purely syntactic convenience). This binding, however, expects all strings to be UTF-8 and doesn't allow passing or receiving arbitrary byte sequences between Rust code and Lua code.Furthermore, this imposition of arbitrary semantics was done in a particularly sloppy way: the code below will panic instead of just returning an
Err(_)
value (which happens for e.g. mismatched types).