[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] Lua 5.3.0 (beta) now available
- From: "Alexandre (gaumerie)" <gaumerie@...>
- Date: Mon, 27 Oct 2014 08:34:52 +0100
It could be an interesting addition to have a capture system in the struct pack/unpack functions, similar to captures in the pattern matching functions.
If one wants to read a C structure, but only needs some values from the structure. Sure, you can:
- read all the data structure and get the values you need from the return values, but so you have to deal with potentially a lot of return values or create a temporary table.
- look for the offset of the values you want to read, and read one by one, but it is more work and you have to deal with data size and alignement in computing the offset.
And it is clean.
Actually I don't see a need for that from my side now, but it seems easy to implement (at first sight, I am not a professional of programming and have not tried), fits naturally with the mechanism and it is easy to find some applications.
What do you think about this?
Thanks a lot for the new beta, it is a really good work.
Alexandre
--- Original Message ---
From: "Roberto Ierusalimschy" <roberto@inf.puc-rio.br>
Sent: 26 October 2014 16:28
To: "Lua mailing list" <lua-l@lists.lua.org>
Subject: Re: [ANN] Lua 5.3.0 (beta) now available
> I see the < and > modifiers in the packing functions to change
> endianness. But AFAICT there is no way to revert to native endianess
> in the middle of a format. I understand it's a very specific use case
> that would mix native endianness and some or both fixed endianness in
> the same struct. But for the sake of completeness it might be nice to
> have some way to reset any configuration to the default. For example
> you could use the pipe/vertical bar character that's not in use at the
> moment.
It could be '=' (as it is in the struct library).
> Finally there is an alignment/padding feature in this new pack/unpack
> code. But the padding value used when packing is not specified. Being
> able to configure the value would be a bit too much, but I think you
> should at least define the value you use (if it's currently undefined)
> and document it.
It is 0. We will document that.
-- Roberto