Messages in this thread | | | Date | Fri, 19 Feb 2016 22:19:00 +0200 | From | Lasse Collin <> | Subject | Re: About support XZ-compressed kernel on x86 |
| |
On 2016-02-18 Baoquan He wrote: > OK. I still don't understand below snippet taken from misc.c. As you > said overwriting happened when the write position quickly approaches > the read position. how could it happpen if the input pointer is moving > faster than the output pointer? > > > * The output pointer can only overrun the input pointer if the input > * pointer is moving faster than the output pointer. A condition only > * triggered by data whose compressed form is larger than the > * uncompressed > * form.
That paragraph is confusing, I agree. Here is a slightly clearer wording:
* The output pointer can only overrun the input pointer if, at some * point in the decompression process, the input pointer is moving * faster than the output pointer. This condition can only be * triggered by data whose compressed form is larger than the * uncompressed form.
I'm afraid it's still not good enough.
Example: Imagine a decompressor whose decompressor loop, on each iteration, first reads exactly one input byte and then writes at least one output byte, until all the data has been decompressed. In this case the input pointer never moves faster than the output pointer (they can move at the same speed though).
This kind of decompressor would need no safety margin for in-place decompression: After reading the last input byte, the decompressor would write one or more output bytes of which the last one would be at the same position as the last input byte was. If the output pointer overtook the input pointer at any point, the last input byte would make the decompressor write past the end of the buffer. That is, the output pointer overtaking the input pointer would be a clear sign that the input file is corrupt: Since the input pointer cannot move faster than the output pointer, the input pointer cannot catch up with the output pointer so that the last output byte wouldn't be written past the end of the buffer.
I hope the above example is clear enough; I'm not able to word it better right now. I don't recommend putting the above example in misc.c, but maybe the example helps in figuring out a better wording for the existing text in misc.c.
In most decompressors, the input pointer moves faster than the output pointer in certain common situations (like file format headers), thus some decompressor-specific safety margin is needed.
-- Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
| |