Re: Questions about string.pack() and string.unpack()

[Oliver Kroth <oliver.kroth@...>]

Hello Roberto,


> > 1) why is in string.pack the default length for c (simple string) 1,
> > and not the string's length?
> Coding a variable-length string without its length would be
> unreadable (there would be no way to unpack it). (In particular,
> we want that anything packed with some format 'f' should be readable
> with exactly the same format.)
There are a few encodings out there that don't put the length of the 
string in front of it
Look at the PKZIP file header; there are three strings involved 
(compressed file content, file name, and comment);
but their length is encoded in a separate field.

Possibly we need a special length encoding that is read from the 
parameter list,
similar to the printf field width (or precision) specifier '*' :
-- get numerics
version, gpf, method, mtime, mdate, crc, compressed. length, namelen, 
extralen,offset = ('<I2I2I2I2I2I4I4I2I2'):unpack(data)
-- get strings
filename, extra, content=("c*c*c*"):unpack( data, offset, namelen, 
extralen, length)

> > pack() throws an error if the string's length does not match the
> > coded length, but there is no method to encode the length as a
> > variable
> Don't you mean option "s"?
No, the s option takes the actual string's length and encodes it in as 
many bytes as specified.
I mean the c option that requires a length that must match the string's 
length.


> > 2) why is there no way to put literal characters into the pack()ed string?
> Binary data usually do not contain fixed stuff. (Even the name 'pack'
> implies not wasting space...). You can always code literal characters
> with a combination of "c" and literal strings.
False for "do not contain fixed stuff". Check RIFF files, PNG, PKZIP.
All of these contain fixed header strings.

True for the "c" plus literal statement

--
Oliver