Csdrhrt

I would like to be able to debug building a binary builder. Right now I am basically printing out the input data to the binary parser, and then going deep into the code and printing out the mapping of the input to the output, then taking the output mapping (integers) and using that to locate the corresponding integer in the binary. Pretty clunky, and requires that I modify the source code deeply to get at the mapping between input and output.

It What seems like you could do is view the binary in different variants (in my case I'd like to view it in 8-bit chunks as decimal numbers, because that's pretty close to the input). Actually, some numbers are 16 bit, some 8, some 32, etc. So maybe there would be a way to view the binary with each of these different numbers highlighted in memory in some way.

The only way I could see that being possible is if you actually build a visualizer specific to the actual binary format/layout. So it knows where in the sequence the 32 bit numbers should be, and where the 8 bit numbers should be, etc. This is a lot of work and kind of tricky in some situations. So wondering if there's a general way to do it.

Also wondering what the general way of debugging this type of thing currently is, so maybe I can get some ideas on what to try from that.

For ad-hoc checks, just use a standard hexdump and learn to eyeball it.

If you want to tool up for a proper investigation, I usually write a separate decoder in something like Python - ideally this will be driven directly from a message spec document or IDL, and be as automated as possible (so there's no chance of manually introducing the same bug in both decoders).

Lastly, don't forget you should be writing unit tests for your decoder, using known-correct canned input.

ASN.1, Abstract Syntax Notation One, provides a way of specifying a binary format.

• DDT - Develop using sample data and unit tests.


• A textual dump can be helpful. If in XML you can collapse/expand subhierarchies.


• ASN.1 is not really needed but a grammar based, more declarative file specification is easier.

The first step to doing this is that you need a way to find or define a grammar that describes structure of the data i.e. a schema.

An example of this is a language feature of COBOL which is informally known as copybook. In COBOL programs you would define the structure of the data in memory. This structure mapped directly to the way the bytes were stored. This is common to languages of that era as opposed to common contemporary languages where the physical layout of memory is an implementation concern that is abstracted away from the developer.

A google search for binary data schema language turns up a number of tools. An example is Apache DFDL. There may already be UI for this as well.