If you were design the worst possible file format, one which maximizes the number of bugs in its parsers, what features would it include?

Let me start:
Length-prefixed everything. Containers (lists, dicts, etc) have a length field in bytes, but all the items inside them also have their own length fields.

@wolf480pl

(It worth noticing that I actually did something like this, somewhere... and they worked like a charm)

@Shamar Microsoft did that too with Windows Registry.

@Shamar boring / too obvious. Also, makes it impossible to add any other nasty features.

@wolf480pl

Actually it's very easy to add pointers. Consider what you can do with function pointers in a struct, for example.

@Shamar well without pointers you can't tell if it's a memory dump or a sane format that someone chose to implement using packed structs.

@wolf480pl

Well... but you are not considering union fields and flexible arrays!

With flexible arrays, for example, you actually need to know the size of the message.

Under certain conditions this doesn't means a size field: for example you could use the file size to compute the size of the array (obviously, if it's not encrypted somehow).

But over the wire, this is a great way to build very funny parsers. 😉

@wolf480pl @Shamar *clears throat* Cap'n'proto doesn't need to have an decoding/encoding step as it is usable in-memory. So you can definitely add nasty features on top of this.

@ignaloidas @Shamar it has those accessors tho that do decoding on-the-fly

@wolf480pl @Shamar It's not as much decoding as it is pointing to the right direction and XORing the contents.

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.