cdata conversion failure with ffi.string()

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

cdata conversion failure with ffi.string()

Markus Korber
Hi there,

I'm trying to use the FFI with the code given here to serialize a C
struct:
https://stackoverflow.com/questions/12344095/how-do-i-convert-a-cdata-structure-into-a-lua-string/12347111#12347111 


However, using Lua 5.1 I always get the following error message: lua:
./temp.lua:22: unable to convert cdata to string
Any idea what can be wrong with ffi.string()?

br,
Markus

Reply | Threaded
Open this post in threaded view
|

Re: cdata conversion failure with ffi.string()

Michal Kottman
On Thu, Mar 7, 2019, 6:27 AM Markus Korber <[hidden email]> wrote:
However, using Lua 5.1 I always get the following error message: lua:
./temp.lua:22: unable to convert cdata to string
Any idea what can be wrong with ffi.string()?

Since I answered that question... Is there a minimal reproducible sample that you can provide to this list?
Reply | Threaded
Open this post in threaded view
|

Re: cdata conversion failure with ffi.string()

奥斯陆君王
In reply to this post by Markus Korber
According to current luaffi implementation, you have to  cast it to void* or char* with length specified if the data doesnot end with '\0' . Use ffi.string(ffi.cast("void*",ms),ffi.sizeof(ms)) to do so.


Reply | Threaded
Open this post in threaded view
|

Re: cdata conversion failure with ffi.string()

Markus Korber
In reply to this post by Markus Korber
On 08.03.19 00:59, qtiuto wrote:
According to current luaffi implementation, you have to  cast it to void* or char* with length specified if the data doesnot end with '\0' . Use ffi.string(ffi.cast("void*",ms),ffi.sizeof(ms)) to do.
Moreover, you can decrypt the message by base64 in lua-I。

Thanks a lot. That's working now!

br,
Markus
Reply | Threaded
Open this post in threaded view
|

Re: cdata conversion failure with ffi.string()

Philippe Verdy
I don't understand why the ffi object, which exposes properties in the encoded structure, is still requiring that the conversion to string (with ffi.string(object, ...)) requires passing the size of the object: isn't the encoded object already encapsulating its inner size ? How can any other value than ffi.sizeof(object) be valid ?
In my opinion using "ffi.string(ms)" should be enough, and we shouldn't even need to recast the pointer to a "void*" (this is where the type info is lost, as if it was a single byte and why you then need to pass again the size in bytes to extend the actual string to create). Such use can just create havoc, possibility security issues (buffer underruns/overruns).
If you don't want to "stringize" a full ffi object, that object should provide an accessor property that will expose just what is needed into a separate FFI object, using a specific constructor, which can then be stringinzed as "ffi.string(ms.accessorproperty)".
It would be much more rock solid. Here you are trying to reproduce the C/C++ hacks in Lua, and such hacks have already caused much security troubles as it is very errorprone, and completely unchecked (the only limit is the Lua memory manager: it protects only two boundaries but not necessarily those used by the actual object, because there may be additional transient/temporary data fields which are supposed to remain "blackboxed" and not exposed (additionally the unexposed fields are not necessarily at start or end of the binary-encoded object, and there may also remain padding areas that also expose old transient states, not necessazrily flushed out).
So I don't understand the interest of such "design" in FFI...


Le ven. 8 mars 2019 à 05:52, Markus Korber <[hidden email]> a écrit :
On 08.03.19 00:59, qtiuto wrote:
According to current luaffi implementation, you have to  cast it to void* or char* with length specified if the data doesnot end with '\0' . Use ffi.string(ffi.cast("void*",ms),ffi.sizeof(ms)) to do.
Moreover, you can decrypt the message by base64 in lua-I。

Thanks a lot. That's working now!

br,
Markus
Reply | Threaded
Open this post in threaded view
|

Re: cdata conversion failure with ffi.string()

奥斯陆君王
In reply to this post by Markus Korber
I fix my luaffi project to emit the len required by the function and
the unnecessary  length required now. But I think you'd better notify
the luajit ower or maintainer plus with the luaffi project owner.
Currently, I'm adding struct support for the luaffi project, and the
fix will be pushed in later this month.
If you're using luaffi rather than luajit, welcome to my project page:
https://github.com/qtiuto/luaffi
Beside this bug, there is still a quite-little complex number argument
bug for arm64 now(no standard function can trigger it).