Re: [ANN] Lua 5.3.0 (work2) now available

[Jerome Vuarand <jerome.vuarand@...>]

I'm the author of one of the higher level serialization libraries, and
would welcome some low level built-ins to help serialization
performance, so I have a some questions regarding the new
packing/unpacking functions.

On mixed-endian architectures, packfloat reads:

    may not work correctly for non-native endianess

and packint reads:

    may not work correctly for native endianess

Is there a mistake for one of the two or are these really different? I
don't think I ever used a mixed-endian computer, but for reliability
I'd rather have all cases be handled properly (my priority is on
"non-native" for binary files and protocols, but I'm also using my
serialization library for a few "native" use cases).

The packint function says it supports any size value from 1 to 8. Is
that any power-of-two value or any integer value? I.e. would it work
with 3 or 7?

Regarding negative integers, can you specify in the manual whether you
use some defined representation (two's complement) or whether you rely
on the C compiler format (which AFAIK may not be two's complement).
I.e. can I reliably expect that I can pack an integer from -8 388 608
to +8 388 607 in a size 3 (24bits) integer? A similar question holds
for floats: do you use the C compiler format or a clearly defined IEEE
binary32 and binary64?

Finally two suggestions. I'd very much enjoy a packuint, since
unsigned integers are as common as signed ones in binary data. I
realize it would be easy to implement on top of packint, but packint
and packfloat can also be implemented on top of string.char.

The other one is not original, but rather to second the proposal from
others to introduce binary literals. When doing non-byte aligned low
level stuff (e.g. composing microcontroller register values, parsing
DVB streams) sometimes hex is as unreadable as decimal and binary
values could help readability. On the other hand it's probably not
possible to leverage the C lib for parsing these numbers, and it might
not be worth the extra custom code.

2014-03-21 20:44 GMT+00:00 Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br>:
> Lua 5.3.0 (work2) is now available for testing at
>         http://www.lua.org/work/lua-5.3.0-work2.tar.gz
>
> MD5     52bd13d0b40f637bc388a133b9bb8771  -
> SHA1    e52ea0acf4b2d7bf042f48bd01dddc149d517184  -
>
> This is a work version. An updated reference manual is included but
> all details may change in the final version. See
>         http://www.lua.org/work/doc/readme.html
>
> The main change in Lua 5.3.0 is the introduction of integers.
> For other changes, see
>         http://www.lua.org/work/doc/readme.html#changes
>
> The complete diffs from work1 are at
>         http://www.lua.org/work/diffs-lua-5.3.0-work1-work2.txt
>
> Enjoy. All feedback welcome. Thanks.
> --lhf
>
>