Re: string.pack with bit resolution

[Sean Conner <sean@...>]

It was thus said that the Great bil til once stated:
> Hi Sean,
> thank you for your answer.
> 
> But above, you were already confirming, that some format string to transfer
> data uniquely between different lua systems is necessary (e. g. LUA_32 <>
> LUA_64, or this would also need uniqueness for LUA_64 (little-endian) <>
> LUA_64 (big_endian)).

  Yes.  As long as you are transferring data among systems of different
types (32 bits, 64 bits, little endian, big endian) you need to define the
format as precisely as possible.  But I don't think Lua format strings good
for doing *that* particular job.  For instance, this format string (which I
do use in a testing tool at work):

	">z I1 I1 z I1 I1 z I1 I1 I1 z z I1 I1 I1 I1 s1" -- [1]

while it conveys the format, it lack any semantics and that alone is not
enough to document the stream.  Even the code in context:

      result.id     = 'SUBMIT_SM'
      result.source = {}
      result.dest   = {}
      
      result.service_type,
      result.source.addr_ton,
      result.source.addr_npi,
      result.source.addr,
      result.dest.addr_ton,
      result.dest.addr_npi,
      result.dest.addr,
      result.esm_class,
      result.protocol_id,
      result.prority,
      result.schedule_time,
      result.validity_period,
      result.registered_delivery,
      result.replace_if_present,
      result.data_coding,
      result.sm_default_msg_id,
      result.message,
      pos = string.unpack(">zI1I1zI1I1zI1I1I1zzI1I1I1I1s1",blob,13)

is, to me, not much better.  I tend to use string.pack()/string.unpack() for
much shorter sequences, or for exploratory purposes.  But I can say the same
thing for CBOR, although CBOR allows one to semantically tag data (if wanted
or needed), and RFC-8610 describes a standard to describe data formats.

> Alignment OF COURSE is an issue in number formats. But I do not know an
> application, where alignment "in a packed number string" would be an issue.
> Or do you want to specify the alignment only for unpack to specify the
> number alignment? ... but unpack of course when creating numbers ALWAYS will
> create lua_Number, and this then of course is the native alignment on the
> machine doing the unpacking?

  It's for when you need it.  I personally haven't had to use the alignment
directives with string.pack()/string.unpack(), but I'm glad they're there in
case they are needed.

  -spc

[1]	The version at work lacks the spaces.