Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-g.b-one.net (mx-g.one.com [91.198.169.54])
	by mail9.b-one.net (Postfix) with ESMTP id E26D5400122
	for <info@awaresystems.be>; Thu, 30 Apr 2009 10:02:50 +0200 (CEST)
X-Virus-Scanned: by one.com
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=0 required=6 tests=[none]
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-g.b-one.net (Postfix) with ESMTP id 3DBE314002AB
	for <info@awaresystems.be>; Thu, 30 Apr 2009 10:02:48 +0200 (CEST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 1B9901D191B29;
	Thu, 30 Apr 2009 03:01:53 -0500 (EST)
Received: from mail-gx0-f179.google.com (mail-gx0-f179.google.com
	[209.85.217.179])
	by lists.maptools.org (Postfix) with ESMTP id 3DE8C1D0E40BE
	for <tiff@lists.maptools.org>; Thu, 30 Apr 2009 02:41:43 -0500 (EST)
Received: by gxk27 with SMTP id 27so1578992gxk.21
	for <tiff@lists.maptools.org>; Thu, 30 Apr 2009 00:41:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.19.72 with SMTP id z8mr1186929iba.6.1241077302854; Thu, 30 
	Apr 2009 00:41:42 -0700 (PDT)
In-Reply-To: <0E2E76C8-CAF8-45B5-BAAD-BDC4939B6CF0@telegraphics.com.au>
References: <op.usz7voo3foqvse@simon.fritz.box>
	<0E2E76C8-CAF8-45B5-BAAD-BDC4939B6CF0@telegraphics.com.au>
Date: Thu, 30 Apr 2009 03:41:42 -0400
Message-ID: <787b0d920904300041y16f836bx87caec73e17e9ebf@mail.gmail.com>
From: Albert Cahalan <acahalan@gmail.com>
To: Toby Thain <toby@telegraphics.com.au>
Cc: TIFF list <tiff@lists.maptools.org>
Subject: Re: [Tiff] Packbits worst case encoded length
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

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.
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
