4 ms·
The ability to pick up byte streams mid-run is not useless. It's required for example to jump to arbitrary locations in a file and make sense of the data you fi
by jstimpfle 7y ago
The ability to pick up byte streams mid-run is not useless. It's required for example to jump to arbitrary locations in a file and make sense of the data you find there.
Imagine a text editor displaying a large CSV file. Wouldn't you mind having to read everything betseen two locations if you jump forward from the one to the other? Or read everything from the start if you jumping backwards? Even if the text editor stores its own synchronization points, it has to read the file completely at least once, which can be annyoing for very large files.
Also, many of the simpler text tools that only look for ASCII bytes wouldn't work. For example, printing the last lines.
Also, I don't know that other sytem, but what about robustness if there's one bad byte somewhere in the file?
- kstenerud 7y agoYou can do the same thing using VLQ, with less wastage. Just scan for the next cleared high bit.
- mirekrusin 7y agoYou can also construct malicious payloads which will DoS many implementations with architecture like that.
- kstenerud 7y agoYou can also trivially defend against that by having a max travel distance of, say, 4.
- ludamad 7y agoIs that guaranteed to catch all valid cases?
- mirekrusin 7y agoExactly, so you arrived at the same conclusion - fixed distance so you can safely pick up stream at arbitrary position.
- kstenerud 7y agoThe difference is that the distance limits would be inherent to the codec itself, rather than taking up extra space in the data stream.