Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-n.b-one.net (mx-n.one.com [91.198.169.61])
	by mail9.b-one.net (Postfix) with ESMTP id 4C09A400125
	for <info@awaresystems.be>; Thu,  5 Feb 2009 20:42:03 +0100 (CET)
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-n.b-one.net (Postfix) with ESMTP id 601C18C68E8
	for <info@awaresystems.be>; Thu,  5 Feb 2009 20:42:01 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id F10921D18E89F;
	Thu,  5 Feb 2009 14:40:59 -0500 (EST)
Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com
	[208.72.237.25])
	by lists.maptools.org (Postfix) with ESMTP id 946D11D1AF366
	for <tiff@lists.maptools.org>; Thu,  5 Feb 2009 14:26:26 -0500 (EST)
Received: from localhost.localdomain (unknown [127.0.0.1])
	by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 520532A799;
	Thu,  5 Feb 2009 14:26:20 -0500 (EST)
Received: from [192.168.2.4] (unknown [67.47.28.121]) (using TLSv1 with
	cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate
	requested)
	by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id
	72AE22A7E5; Thu,  5 Feb 2009 14:26:12 -0500 (EST)
Message-ID: <498B3D49.2030202@pobox.com>
Date: Thu, 05 Feb 2009 14:26:01 -0500
From: Frank Warmerdam <warmerdam@pobox.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
References: <498B321F.3000300@pobox.com>
	<Pine.SOC.4.64.0902051303550.12379@freddy.simplesystems.org>
In-Reply-To: <Pine.SOC.4.64.0902051303550.12379@freddy.simplesystems.org>
X-Pobox-Relay-ID: DDE49F9C-F3BA-11DD-B555-6F7C8D1D4FD0-06493634!a-sasl-quonix.pobox.com
Cc: TIFF mailing list <tiff@lists.maptools.org>
Subject: Re: [Tiff] assertions, and building with DEBUG/NDEBUG
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

Bob Friesenhahn wrote:
>> It appears these assertions are being used to call to attention problems
>> in these files for developers, and are intended to be compiled out in
>> production software.
> 
> Assertions should only be used to detect logic problems in the libtiff 
> implementation or perhaps the using application.  It would be a bug if 
> an assertion is thrown by libtiff (rather than returning a warning or 
> error) based on reading a file.

Bob,

I agree.  I have removed some particular assertions in tif_readdir.c
now that were really just indicative of corrupt files that were already
being trapped appropriately with runtime errors.

>> So my question is, is it normal for people building for production 
>> purposes
>> to build with NDEBUG defined?
> 
> I have not heard of a build production process for open-source based 
> systems which intentionally disables assertions.  More than likely they 
> are disabled in quite a few closed-source applications.

It has always been my practice and assumption that assertions should
be disabled in production software where performance and appropriate
error handling is considered important.

>> I am contemplating modifying tiffiop.h to explicitly define NDEBUG if
>> DEBUG is not defined, before including assert.h.  This would mean that
>> assertions are compiled out by default, and only included if DEBUG is
>> explicitly requested.  I would also change Makefile.vc to define DEBUG 
>> for
>> the debug build case.
> 
> This is a sure-fire way to ensure that there are no bug-reports 
> regarding thrown assertions.  Is that really what we want?  Maybe we are 
> using the assertions incorrectly.

As noted, some of the assertions have been removed as inappropriate.

However, I still feel it is a questionable practice to leave assertions
compiled in to production builds.  For now though I'll take no further
action in this regard.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
