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...
