Package: file
Version: 4.23-2
Severity: wishlist
It often makes more sense to just specify that the next item in a
structure comes right after the previous item (possibly after some
padding), rather than having to specify the offset from the beginning
of the structure.
Prefixing an offset with & makes it relative to the last item at a
higher level (one fewer '>'). However, taking advantage of that
requires increasing the nesting level after each field, which creates
very deep hierarchies and makes entries hard to read. I'd really like
a syntax for an offset relative to the last item at the same level.
For example, consider a file format like this:
0 string SomeFileFmt\x0 Some file format
>12 ubelong !0 \b, version %u
>12 ubelong 0 \b, version 0
>>16 ubeqdate x \b, last modified %s
>>24 ubyte x \b, thing1 %hhu
>>25 ubyte x \b, thing2 %hhu
>>26 ubeshort x \b, thing3 %hu
>>28 ubelong x \b, thing4 %u
>>32 ubequad x \b, thing5 %llu
>>40 ubyte x \b, thing6 %hhu
>>44 ubelong x \b, thing7 %u
To write that entry, I had to manually accumulate the sizes of fields
(including string lengths) and any padding (in this case, the 3 bytes
after thing6). If I add an item in the middle, or change the size of
a field or the length of a string, I have to adjust all the subsequent
offsets, and take the (implicit) padding into account.
I can improve it slightly by using the existing relative offsets:
0 string SomeFileFmt\x0 Some file format
>&0 ubelong !0 \b, version %u
>&0 ubelong 0 \b, version 0
>>&0 ubeqdate x \b, last modified %s
>>&8 ubyte x \b, thing1 %hhu
>>&9 ubyte x \b, thing2 %hhu
>>&10 ubeshort x \b, thing3 %hu
>>&12 ubelong x \b, thing4 %u
>>&16 ubequad x \b, thing5 %llu
>>&24 ubyte x \b, thing6 %hhu
>>&28 ubelong x \b, thing7 %u
This avoids the need to deal with the size of the magic string and
version number, but I still have to accumulate sizes and padding when
decoding the version 0 format.
If I change the nesting, I can use entirely relative offsets:
0 string SomeFileFmt\x0 Some file format
>&0 ubelong !0 \b, version %u
>&0 ubelong 0 \b, version 0
>>&0 ubeqdate x \b, last modified %s
>>>&0 ubyte x \b, thing1 %hhu
>>>>&0 ubyte x \b, thing2 %hhu
>>>>>&0 ubeshort x \b, thing3 %hu
>>>>>>&0 ubelong x \b, thing4 %u
>>>>>>>&0 ubequad x \b, thing5 %llu
>>>>>>>>&0 ubyte x \b, thing6 %hhu
>>>>>>>>>&3 ubelong x \b, thing7 %u
However, the nesting quickly becomes unmanageable. Also, if the
decoding of the version 0 format required any legitimate use of
nesting, such as for conditional decoding or multiple decoding of the
same field, this artificial nesting will break.
Now, compare that to how it might look with a new relative offset
prefix '+', meaning "offset from end of previous field at same level":
0 string SomeFileFmt\x0 Some file format
>&0 ubelong !0 \b, version %u
>&0 ubelong 0 \b, version 0
>>&0 ubeqdate x \b, last modified %s
>>+ ubyte x \b, thing1 %hhu
>>+ ubyte x \b, thing2 %hhu
>>+ ubeshort x \b, thing3 %hu
>>+ ubelong x \b, thing4 %u
>>+ ubequad x \b, thing5 %llu
>>+ ubyte x \b, thing6 %hhu
>>+3 ubelong x \b, thing7 %u
For added simplicity, add another prefix ('=' in this example) meaning
"offset from the beginning of the previous field", and make these both
look at the next higher level if no previous field exists at the same
level:
0 string SomeFileFmt\x0 Some file format
>+ ubelong !0 \b, version %u
>= ubelong 0 \b, version 0
>>+ ubeqdate x \b, last modified %s
>>+ ubyte x \b, thing1 %hhu
>>+ ubyte x \b, thing2 %hhu
>>+ ubeshort x \b, thing3 %hu
>>+ ubelong x \b, thing4 %u
>>+ ubequad x \b, thing5 %llu
>>+ ubyte x \b, thing6 %hhu
>>+3 ubelong x \b, thing7 %u
This seems vastly simpler.
- Josh Triplett
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages file depends on:
ii libc6 2.7-8 GNU C Library: Shared libraries
ii libmagic1 4.23-2 File type determination library us
file recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
