@MSGID: 1@dont-email.me> 47da708e
@REPLY: <64f26b69@news.ausics.net> 47859597
@REPLYADDR Janis Papanagnou
<janis_papanagnou+ng@hotmail.com>
@REPLYTO 2:5075/128 Janis Papanagnou
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References: 1@dont-email.me>
<64f26b69@news.ausics.net>
@TZUTC: 0200
@PID: Mozilla/5.0 (X11; Linux x86_64; rv:45.0)
Gecko/20100101 Thunderbird/45.8.0
@TID: FIDOGATE-5.12-ge4e8b94
On 02.09.2023 00:53, Computer Nerd Kev wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> The `od` tool allows displaying binary data in various formats, but
>> it works on a whole data stream (not on individual fields).
>> Are there any tools that support a more flexible inspection of binary
>> data?
>>
>> I was thinking of some data specification and a tool to work with that
>> specification and binary data files. My current experimental hack has
>> a data specification of a form as shown in this example
> 
> If I`m following you, then this sounds like a description of
> something like GNU Poke:
> 
> http://www.jemarch.net/poke
> 
> Not something I`ve had a use for myself since finding out about it
> recently, but it seems like a comprehensive solution to the
> problem.

This is really overwhelming! - Indeed it seems to cover what I was
looking for, but yet much much more; a complete programming language
with control constructs and exception handling, just to name one big
part of the package. So I`m not quite decided that it`s what I`d use.
I certainly don`t want to write a program[*] to extract some data,
for my purpose the advertised declarative approach[**] would be it.
I`ll have to work through the docs to see whether some basic features
are actually supported (e.g. I`m not sure whether simple fixed length
strings (without \0 termination) are supported; I suppose they are,
but some statement I read in the docs made me cautious, so I`ll have
to see). - All in all an interesting tool, so thanks for the link!

BTW, in the poke docs I saw examples WRT endian`ness, like the spec
    little int a;
    big int b;
    int c;
In the past I`ve assumed that endian`ness is a machine characteristic
and would not change within a protocol element. The example taken from
the poke docs suggests that there may be different elements. Of course
we can think about different payload data in a single protocol element,
but is that usual? - I`m coming from the ITU-T ASN.1/BER perspective,
where the ASN.1 data spec is agnostic and endian`ness should happen
in the encoding and decoding process for a specific source and target
architecture. - The answer would lead either to a data spec (like in
poke) to specify that property separately with every data element, or
as a single parameter for the processing.

Janis

[*] An example can be found in the poke docs:
http://www.jemarch.net/poke-3.3-manual/poke.html#elfextractor

[**] http://www.jemarch.net/poke-3.3-manual/poke.html#Motivation

--- Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5075/128
@PATH: 5075/128 5020/1042 4441