break broken code
Message-Id: https://www.5snb.club/w/break-broken-code/
Linked-From: wiki.
the robustness principle is wrong
follow the specification in what you accept, emit thing that do happen to follow the specification, and no more
everyone should be fuzzing for bad implementations at all times.
If something truly cannot be changed because it would break too much stuff and you don’t have the political power to get people to not be broken, change the specification to be more restrictive on what can be generated, to be what people actually accept. (Changing the spec to tighten up what you’re allowed to reject would be bad, since then previously correct code would break, but tightening up emission to be “this is invalid, but if you see it, you have to accept it”) is fine.
It’s admitting defeat, but at least that way you know what you can do.
See: ImperialViolet - The several canons of CBOR (which mentions LWN - Networking change causes distribution headaches)
examples
various things with varints allow overlong encodings (encoding a varint in more space than strictly needed).
I brought this up in relation to the TinyVG specification, and it was decided that overlong encodings are perfectly valid and not forbidden (as long as they’re 5 bytes or less).
The new text looks like
Overlong Encodings
The above encoding means that there are multiple ways to encode some values, and decoders must be prepared to handle that.
Integer Value Byte Sequence 0 80 80 80 80 001 80 80 80 80 01The maximum length of an encoded value is 5 bytes. Decoders must reject the following values.
Error Reason Bytes Sequence Went 5 bytes without ending 80 80 80 80 80 00Encodes a value greater than 2³² FF FF FF FF 1F
Which still makes it clear that you must handle overlong encodings.