From: Joel VanderWerf <vjoel@...>
Date: 2006-06-06T06:08:03+09:00
Subject: Re: Like BitStruct, but better?

Ben Nagy wrote:
> Hi all,
> 
> So what I'm really looking for is something that is like the (reasonably
> cool) bit-struct library, but with some improvements. I don't mind hacking a
> bunch of stuff onto a more generic format / library if I have to.
> 
> What I need is a way to rapidly build classes that represent structured,
> binary data. Bit-struct only lets me define fields up to 32 bits long, which
> is bad, and there isn't (AFAICT) a way to have variable length fields in
> mid-structure. As an example I might want to represent a protocol header
> which has a Length field followed by some data of the appropriate length,
> and then followed by some more fixed structure elements. 

Hi, Ben.

Unsigned and signed integer fields >32 bits (and 1..16, 24, or 32 bits)
are supported since bit-struct-0.8. And of course the various character
field types can be any _fixed_length.

However, you're right about variable length fields that occur somewhere
except at the end of the structure: bit-struct doesn't support them.

For the special case of protocols with (for example) IP option fields,
I've been lucky enough to deal with only a small set of possibilities,
and I just define each of them as a different subclass of IP, with fixed
length fields. I define a #parse class method that looks at the header
length or flags to determine what type it should be, and then outputs an
instance of the appropriate subclass.

If you want to handle variable length embedded fields in a single class,
 that's going to be tricky. How long are the length fields? Are the
length fields fixed length? Or are they like netstrings[1]? Encoded as
ascii, big-endian unsigned, or ...?

When you access fields at a higher offset than the beginning of the
var-length field, the accessor will have to read the length and adjust
the offset accordingly. If there is another var-length field, that may
require skipping past that field as well...

Anyway, I have wanted such a field, too, so maybe I will implement one
of these variations someday. Or if anyone has ideas...

[1] http://cr.yp.to/proto/netstrings.txt

-- 
      vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407