Re: string.pack with bit resolution

[bil til <flyer31@...>]

Hi Sean,
thank you for your answer.

Sorry for my ironic start, this was ironic, I have to admit.

Concerning the "wicked 0x80" problem, you maybe program mainly on large
systems - in case of large ints 4byte or more you hardly ever reach such
limit. But if you program controllers which often use 1byte for a number,
then this really can be very dangerous, believe me.

Concerning 1bit, I have to defend them. Then in my opinion clearly unsigned
0/1... (and if you consider them as signed, then also no problem, as it
boolean requests in C it does not matter, whether the result is 0/1 or
0/-1).

The problem with the sign only appears with the 2nd bit... .

Thank you for the Erlang bit syntax example, but this is somewhat too much
for me (I always strike with these strange string search patterns used for
string.match etc... I must admit ... of course they are nice for many
applications, but I am always happy if I can avoid them...).

My proposal for this # and ^ is only meant as request TWO (and inferior) ...
if you do not like this, then also fine, no problem. Just please at least
add the bits. (and n1..7 already very fine...).

Just I think this # and ^ concept would increase the flexibility of this
pack/unpack functions tremendously, and it will NOT lead to much further
programming overhead in C, I am quite sure.

Of course I principally COULD program this myself. But it would be a very
large advantage, if such a format is uniquily defined by somebody with
"wider fan group", like e. g. lua ... then to communicate such format
strings to other people, you just could specify "format string in lua-style"
- would be very nice and useful in my point of view.

Just it really has to be unique, and my side remarks concerning n, j and J
ARE important... . It must clearly be defined such, that no problem to pack
e. g. on a lua 64bit device, and then unpack on lua 32bit device and vc vs
... otherwise this pack/unpack does not make too much sense. I really think
best kill j and J, and keep n, but with 1 additional typinfo byte at the
start. (and for this n type I would always use signed ints, as lua anway
always does... if somebody wants unsigned ints, I4 or I8 is a perfect
choice).

64bit int is NO problem with I8 and i8, even in the lua5.3 version of
pack/unpack.

The native size of course is nice, but it has to be included into the
string, otherwise the unpacker is mixed up if he should get the task to
unpack on another system... . Therefore I think much better to include this
as type info in n, and then all fine, j and J not needed any more. (n of
course IS native size, but it really has to specify this "native info" in
the result string somehow...).

I really think that these add's to pack and unpack would be easy to
implement.

Just not easy to get agreement in the community ...

and before no agreement in the community, it makes no sense to start
programming ...

(as a main goal of these format definition clearly must be to transfer data
in uniquely described form from one system to another, at least from lua
32bit to lua 64bit and vc vs - I hope you completely agree with this at
least).










--
Sent from: http://lua.2524044.n2.nabble.com/Lua-l-f2524044.html