[lxgr]

> Many low level things are basically packed C-structs with this type of protocol.

Not really: C structs notably don't have variable-length fields, but ISO 8583 very much does.

To add insult to injury, it does not offer a standard way to determine field lengths. This means that in order to ignore a given field, you'll need to be able to parse it (at least at the highest level)!

Even ASN.1, not exactly the easiest format to deal with, is one step up from that (in a TLV structure, you can always skip unknown types by just skipping "length" bytes).

[david-gpu]

> Not really: C structs notably don't have variable-length fields

Feast your eyes: C99 introduced an ~~abomination~~ feature called flexible array members (FAM), which allows the last member of a struct to be a variable length array.

If you want to ~~gouge you eyes~~ learn more, see section 6.7.2.1.16 [0].

> To add insult to injury, it does not offer a standard way to determine field lengths

That's awful. You can sort of say the same about variable length struts in C, but at least the strict tupe definition usually has a field that tell you the length of the variable length array at the end.

[0] https://rgambord.github.io/c99-doc/sections/6/7/2/1/index.ht...

[lxgr]

> [...] feature called flexible array members (FAM), which allows the last member of a struct to be a variable length array.

Oh, ISO 8583 has these too!

Sometimes they're even combined with the "feature" described in the article where there's a variable number of fixed-length elements, except for the last element, which is a variable-length string (or sometimes the last field type repeated n times). That's always "fun" to work with.

ISO 8583 really is a living museum of all ideas people had about binary encoding in the last half century or so.

[j16sdiz]

FAM was a (not so successful) attempt to standardise some existing usage