rzumer / libreips Goto Github PK

Decoders may (and in LibreIPS's case, will) interpret this as an EOF marker.

If a chunk should begin on this byte, rewind to the previous byte and start a record there instead.

This would have implications on lookahead (#2) as well.

• Unit tests
• Performance tests

This requires buffering the output bytes instead of record chunks. Only one record would be needed in memory, and management would be simpler, as it could be kept in the stack (the data will still be malloc()ed).

The goal is to get better performance by avoiding the allocation of record chunks. Performance tests would be useful to implement before trying this.

An alternative would be to store all records on the stack, but with large patches the cost could be prohibitive.

The reference implementation does not support truncation, but it is a commonly-used and supported extension.

Currently, when applying a patch, the output file is assumed to be the same size as the input. This is not necessarily the case, as a patch can write additional data at the end of the original file.

This will likely require an API change.

Similar to #6, but at the decoder side. This should be relatively simple to handle by attempting to parse a size and data sequence if this is encountered in-loop.

As pointed out here, it is not possible to apply a patch beyond the sum of the maximum offset and size.

As a first step, the encoder should return, and the CLI indicate that an internal error has occurred. Better error handling, and support for encoding up to the sum of the maximum offset and the maximum size, can come later.

Should be done to determine whether or not it is worth closing a record, considering header overhead.