2009.04.30 07:41 "Re: [Tiff] Packbits worst case encoded length", by Albert Cahalan

On Wed, Apr 29, 2009 at 10:28 AM, Toby Thain <toby@telegraphics.com.au> wrote:

On 26-Apr-09, at 1:22 PM, Simon Berger wrote:

If you need your code to be robust against corrupt input then you should stop decompressing when the row is full, though of course you will lose sync with the input.

There is no "if".

If the row doesn't come out even, you have 4 choices:

1. give up, and throw away the partial image
2. zero the rest of the output, then give up
3. wrap to the next row
4. throw away the extra pixels

If rows follow each other in memory, then #3 is natural.

Otherwise, a bit of padding on each row (128 bytes?) makes #4 natural. You safely overflow into the padding.

At the end of the image, you should be using a guard page. It's not good to assume that all your code was OK.

A guard page will stop you cold if you go over.

On platforms that allow recovery from a memory violation, a guard page even lets you eliminate lots of error code. Performance and security improve together.