From: Phrogz <gavin@...>
Date: 2007-06-20T03:10:23+09:00
Subject: Re: Unpacking signed shorts and integers with specified endianness

On Jun 18, 4:32 pm, Phrogz <g...@refinery.com> wrote:
> 1) I see "l" (lowercase L) which is 4 bytes treated as a signed
> integer...but in 'native' endian order. Does String.unpack not provide
> a way to unpack a 4-byte signed integer with a specified endianness?
>
> 2) I see "s" which is 2 bytes treated as a signed integer...but in
> 'native' endian order. Does String.unpack not provide a way to unpack
> a 2-byte signed integer with a specified endianness?

Alright, let's try asking this question a different way. Given a
binary file spec like the following, where the first byte tells you
whether to interpret the rest of the file as little- or big-endian,
and given the presence of a signed integer in the file, how would you
write a parser for this?

endian     UINT8    (1==little, 0==big)
job_count  UINT8    # of repeated binary sections following this
(jobs)     JOB*

    Each JOB section is:
    foo    UINT8
    bar    UINT16
    jim    UINT32
    jam    INT32
    jill   UINT8

gib_mark   0xdead   # 2 bytes
gib_count  UINT16   # of repeated binary sections following this
(gibs)     GIB+

    Each GIB section is:
    gob    8 chars
    blurb  UINT8


Would you invent a new character for String.unpack, split the string
around it, and use knowledge of the native endianness of the platform
you're running on to decide whether to pull out those 4 bytes
independently, reverse them, and then unpack the result as a signed
integer?

Is there some sweet trick you could do after extracting 4 bytes as an
integer to switch the implied interpreted endianness?

Would you patch String.unpack in C to add options for specific-endian
signed shorts and integers?

Can you easily do the above (including the repeating sub-binary
sections) with BitStruct?