allow VLA serialization with t=254

[sonoro1234]

This solves issue #27

[sonoro1234]

I can add your proposed pcall solution for issue #25 if you wish.

[adriweb]

Type IDs are going to conflict very soon :( Should some "extended type ID marker" be assigned soon? As in, if 254/255, the next byte is a new type id. effectively giving 255 more free IDs

[gvx]

I would like to see if I can fold VLAs and VLSs into type code 252 first.

@adriweb Yes, in my head I'd already reserved type code 255 for some kind of "extended type" thing. I'm not sure what the semantics of it are going to be yet.

[sonoro1234]

So, what is going to be done'

[sonoro1234]

Another way to distinguish VLA and VLS is that ffi.sizeof(ty,0)~=ffi.sizeof(ty,1)

[gvx]

Apologies, I haven't looked at bitser for the past 3 1/2 year. Right now I can't promise anything, but I hope I can find the time to get reacquainted with bitser, luajit and your proposed fixes in January.

[sonoro1234]

meanwhile I have implemented another option in https://github.com/sonoro1234/anima/blob/master/anima/cdataser.lua
It uses ffi-reflect to recreate the table that would be used with ffi.new. That sould be combined with a more general serializer as Ser just to pluk the cdata.
The advantage would be that it is endianess safe which I am afraid it doesnt happen with binary serialization!!

[gvx]

That is probably the way to go. I'm currently attempting to fix serialization of ctype and cdata values, which is difficult due to ffi.typeof sometimes returning the wrong ctype.

I'm tempted to declare all ctype/cdata/VLA/VLS values beyond the scope of bitser. In good news, I have an extension API ready to go, so I could write an extension for cdata stuff that depends on ffi-reflect.

The advantage would be that it is endianess safe which I am afraid it doesnt happen with binary serialization!!

Even without cdata etc, bitser is not endian-safe, I should probably add something about that in the README.

[gvx]

This PR is no longer applicable since c95cb0d.