Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-m.b-one.net (mx-m.one.com [91.198.169.60])
	by mail9.b-one.net (Postfix) with ESMTP id 230B340012E
	for <info@awaresystems.be>; Thu, 29 Oct 2009 19:41:27 +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-m.b-one.net (Postfix) with ESMTP id 892261927E1C
	for <info@awaresystems.be>; Thu, 29 Oct 2009 19:41:25 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 8D2651D193CDE;
	Thu, 29 Oct 2009 13:40:21 -0500 (EST)
Received: from toronto2.smartgames.ca (toronto2.smartgames.ca [204.15.192.18])
	by lists.maptools.org (Postfix) with ESMTP id 3E31C1D18B157
	for <tiff@lists.maptools.org>; Thu, 29 Oct 2009 13:22:35 -0500 (EST)
Received: from [10.143.176.101] (unknown [10.143.176.101])
	by toronto2.smartgames.ca (Postfix) with ESMTP id F260116C5A;
	Thu, 29 Oct 2009 14:22:58 -0400 (EDT)
In-Reply-To: <4AE9D44C.5010807@cybox.com>
References: <mailman.7.1256835602.18446.tiff@lists.maptools.org>
	<4AE9D44C.5010807@cybox.com>
Mime-Version: 1.0 (Apple Message framework v753.1)
Message-Id: <3847020C-62E1-45A9-9445-DDA2022672BC@telegraphics.com.au>
From: Toby Thain <toby@telegraphics.com.au>
Date: Thu, 29 Oct 2009 14:21:48 -0400
To: Richard Nolde <richard.nolde@cybox.com>
X-Mailer: Apple Mail (2.753.1)
Cc: tiff@lists.maptools.org
Subject: Re: [Tiff] Tiff Digest, Vol 65, Issue 9
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 29-Oct-09, at 1:43 PM, Richard Nolde wrote:

> I cannot check tiffcrop today as I have to rush off to a meeting  
> through
> 18" of snow but I am aware of the warnings. They derive from the way I
> read and pack data of various bit depths by casting an address to a
> various sizes in order to grab only 8,16,24, or 32 bits from a given
> memory location.  I could probably use unions but it will take some  
> time
> to check the results.

I don't think union will help you much here.

You can avoid pointer casts like the one on line 2817
	buff1 = *((uint16 *)swapbuff);

by open coding, e.g.
	buff1 = (src[0] << 8) | src[1]; // if source data is BigEndian
or
	buff1 = (src[1] << 8) | src[0]; // if LittleEndian

As well as being platform independent, this should be simpler.

--T

> The functions in question deal with the
> endianness of the data on the fly, so it may take some time to silence
> the warnings and test.
>
> As far as I know, the tiffcrop code in 3.9.* and 4.0 should all be the
> same so any differences in warnings would be the result of changes in
> build flags and/or include files.
>
> Richard Nolde
> On 10/29/2009 11:00 AM, tiff-request@lists.maptools.org wrote:
>> Send Tiff mailing list submissions to
>> 	tiff@lists.maptools.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> 	http://lists.maptools.org/mailman/listinfo/tiff
>> or, via email, send a message with subject or body 'help' to
>> 	tiff-request@lists.maptools.org
>>
>> You can reach the person managing the list at
>> 	tiff-owner@lists.maptools.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Tiff digest..."
>>
>>
>> Today's Topics:
>>
>>     1. Re: extending tags in "a"ppend mode? (Juergen Buchmueller)
>>     2. Re: Number of images in a multi-tiff file? (Mark Pereira)
>>     3. Re: extending tags in "a"ppend mode? - solved
>>        (Juergen Buchmueller)
>>     4. Libtiff release soon, please advise (Bob Friesenhahn)
>>     5. Re: Libtiff release soon, please advise (Edward Lam)
>>     6. Re: Libtiff release soon, please advise (Bob Friesenhahn)
>>     7. Re: Libtiff release soon, please advise (Edward Lam)
>>     8. Re: Libtiff release soon, please advise (Bob Friesenhahn)
>>
>>
>> --------------------------------------------------------------------- 
>> -
>>
>> Message: 1
>> Date: Wed, 28 Oct 2009 18:41:23 +0100
>> From: Juergen Buchmueller<pullmoll@t-online.de>
>> Subject: Re: [Tiff] extending tags in "a"ppend mode?
>> To: tiff@lists.maptools.org
>> Message-ID:<20091028184123.aef7f387.pullmoll@t-online.de>
>> Content-Type: text/plain; charset=US-ASCII
>>
>> On Wed, 28 Oct 2009 17:28:34 +0100
>> Juergen Buchmueller<pullmoll@t-online.de>  wrote:
>>
>>
>>> See attachment. This crashes when I try to run it on the file:
>>>
>> Funny enough the crash goes away if I choose a different name for  
>> my own
>> tags. Perhaps a collision or lazy assumption with the autogenerated
>> names (which would be the same)?
>>
>> -                snprintf(buff, sizeof(buff), "Tag %d", id);
>> +                snprintf(buff, sizeof(buff), "test%d", id);
>>
>> Now the test program runs without error message, yet the TIFF file
>> doesn't contain the new tags. Hmm...
>>
>> Juergen
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 28 Oct 2009 23:17:13 +0530
>> From: Mark Pereira<mark@softjin.com>
>> Subject: Re: [Tiff] Number of images in a multi-tiff file?
>> To: Frank Warmerdam<warmerdam@pobox.com>
>> Cc: tiff@lists.maptools.org
>> Message-ID:<4AE883A1.4080908@softjin.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Thanks Frank for these clarifications !
>>
>> Mark
>>
>> Frank Warmerdam wrote:
>>
>>> Brad Hards wrote:
>>>
>>>
>>>> On Wednesday 28 October 2009 20:01:21 Mark Pereira wrote:
>>>>
>>>>
>>>>> Is there a way to know the number of images present in a multi- 
>>>>> tiff file
>>>>> in constant time.
>>>>>
>>>>>
>>>> TIFFNumberOfDirectories() ?
>>>>
>>>>
>>> Mark,
>>>
>>> No, there is not since the directory list needs to be walked to  
>>> count them.
>>> The count is not available in a header or anything like that.
>>>
>>> Skimming the code briefly it appears that TIFFNumberOfDirectories 
>>> () is careful
>>> to read the minimum amount of information from the file (a few  
>>> numbers from
>>> the start of each directory) to count through the file so the  
>>> cost should
>>> be minimal, but not constant time.
>>>
>>> Best regards,
>>>
>>>
>>
>>
>> Business Disclaimer
>> ____________________________________________________________
>> This e-mail message and any files transmitted with it are intended  
>> solely
>> for  the use  of the  individual or entity  to which they  are   
>> addressed. It
>> may  contain confidential,  proprietary or legally  privileged   
>> information.
>> If  you  are  not  the  intended recipient please be advised that  
>> you have
>> received  this  message in error and any use is strictly  
>> prohibited. Please
>> immediately  delete it  and all copies of it from your system,  
>> destroy any
>> hard  copies  of  it and  notify  the  sender  by return mail. You  
>> must not,
>> directly or indirectly, use,  disclose,  distribute, print, or  
>> copy any part of
>> this message if you are not the intended recipient.
>> ___________________________________________________________
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.maptools.org/mailman/private/tiff/attachments/ 
>> 20091028/0357175c/attachment-0001.htm
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 28 Oct 2009 18:46:30 +0100
>> From: Juergen Buchmueller<pullmoll@t-online.de>
>> Subject: Re: [Tiff] extending tags in "a"ppend mode? - solved
>> To: tiff@lists.maptools.org
>> Message-ID:<20091028184630.26999537.pullmoll@t-online.de>
>> Content-Type: text/plain; charset=US-ASCII
>>
>> Ok, the problem seems to be solved now.
>>
>> I need to choose tag names different from the ones that libtiff would
>> use on the auto-registration when reading a file, and I need to call
>> TIFFWriteDirectory() after writing the tags and before closing the  
>> file
>> again.
>>
>> Perhaps this little episode helps others in similiar situations.
>>
>> Cheers,
>> Juergen
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 28 Oct 2009 17:43:33 -0500 (CDT)
>> From: Bob Friesenhahn<bfriesen@simple.dallas.tx.us>
>> Subject: [Tiff] Libtiff release soon, please advise
>> To: Tiff List<tiff@lists.maptools.org>
>> Message-ID:
>> 	<alpine.GSO.2.01.0910281737540.1964@freddy.simplesystems.org>
>> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
>>
>> I plan to cut new libtiff releases soon.  While I don't intend to fix
>> all existing (or many) known bugs before those releases are cut (and
>> there are many bugs listed in libtiff bugzilla), this would be a good
>> time to remind of any dire issues known to exist which should
>> definitely be fixed before a libtiff release.
>>
>> The bug tracker for libtiff is here:
>>
>>     http://bugzilla.maptools.org/buglist.cgi?product=libtiff
>>
>> Thanks,
>>
>> Bob
>> --
>> Bob Friesenhahn
>> bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/ 
>> bfriesen/
>> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Wed, 28 Oct 2009 22:27:04 -0400
>> From: Edward Lam<edward@sidefx.com>
>> Subject: Re: [Tiff] Libtiff release soon, please advise
>> To: Bob Friesenhahn<bfriesen@simple.dallas.tx.us>
>> Cc: Tiff List<tiff@lists.maptools.org>
>> Message-ID:<4AE8FD78.1050704@sidefx.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Bob Friesenhahn wrote:
>>
>>> I plan to cut new libtiff releases soon.  While I don't intend to  
>>> fix
>>> all existing (or many) known bugs before those releases are cut (and
>>> there are many bugs listed in libtiff bugzilla), this would be a  
>>> good
>>> time to remind of any dire issues known to exist which should
>>> definitely be fixed before a libtiff release.
>>>
>> I only looked at what caught my eye on the list. Bug 2001 seems like
>> important low hanging fruit to do before final release:
>>       http://bugzilla.maptools.org/show_bug.cgi?id=2001
>>
>> Basically, it is saying that we should be adding -fno-strict- 
>> aliasing to
>> the gcc (3+?) compiler options when compiling with -O2. Probably  
>> none of
>> libtiff was written with strict aliasing in mind? If so, it sounds  
>> like
>> a good and easy thing to do for avoiding potential bad code  
>> generation.
>>
>> Regards,
>> -Edward
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Wed, 28 Oct 2009 21:58:53 -0500 (CDT)
>> From: Bob Friesenhahn<bfriesen@simple.dallas.tx.us>
>> Subject: Re: [Tiff] Libtiff release soon, please advise
>> To: Edward Lam<edward@sidefx.com>
>> Cc: Tiff List<tiff@lists.maptools.org>
>> Message-ID:
>> 	<alpine.GSO.2.01.0910282139070.1964@freddy.simplesystems.org>
>> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>>
>> On Wed, 28 Oct 2009, Edward Lam wrote:
>>
>>> I only looked at what caught my eye on the list. Bug 2001 seems like
>>> important low hanging fruit to do before final release:
>>>     http://bugzilla.maptools.org/show_bug.cgi?id=2001
>>>
>>> Basically, it is saying that we should be adding -fno-strict- 
>>> aliasing to the
>>> gcc (3+?) compiler options when compiling with -O2. Probably none  
>>> of libtiff
>>> was written with strict aliasing in mind? If so, it sounds like a  
>>> good and
>>> easy thing to do for avoiding potential bad code generation.
>>>
>> I agree that these issues should be avoided, but don't think that
>> -fno-strict-aliasing is the answer since it surely makes the code
>> slower.  I did fix many of the aliasing warnings.  The CVS HEAD
>> version only produces these from the library code:
>>
>> libtiff/tif_dirread.c: In function 'TIFFFetchNormalTag':
>> libtiff/tif_dirread.c:2922: warning: dereferencing pointer 'value. 
>> 235' does break strict-aliasing rules
>> libtiff/tif_dirread.c:2922: note: initialized from here
>> libtiff/tif_dirread.c:2942: warning: dereferencing pointer 'value. 
>> 239' does break strict-aliasing rules
>> libtiff/tif_dirread.c:2942: note: initialized from here
>>
>> Several utilities produce such warnings, and particularly 'tiffcrop'
>> in CVS HEAD spews lots of them.
>>
>> The libtiff from CVS branch-3-9 (which would be 3.9.2) produces no
>> aliasing warnings from the library, and just a few warnings about
>> uninitialized variables in some of the utilities.  I am not sure why
>> tiffcrop in branch-3-9 does not spew the same sort of warnings  
>> that it
>> does in CVS HEAD, but I suspect that it was developed against release
>> 3.9.X code.
>>
>> The GCC (4.4.2) flags used for testing compilation are
>>
>>     -g -O2 -Wall -Winline -W -Wformat-security -Wpointer-arith
>>     -Wdisabled-optimization -Wno-unknown-pragmas
>>
>> Can you please re-check your builds with CVS libtiff and see if you
>> see similar results?
>>
>> Bob
>> --
>> Bob Friesenhahn
>> bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/ 
>> bfriesen/
>> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Wed, 28 Oct 2009 23:54:45 -0400
>> From: Edward Lam<edward@sidefx.com>
>> Subject: Re: [Tiff] Libtiff release soon, please advise
>> To: Bob Friesenhahn<bfriesen@simple.dallas.tx.us>
>> Cc: Tiff List<tiff@lists.maptools.org>
>> Message-ID:<4AE91205.2050407@sidefx.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Bob Friesenhahn wrote:
>>
>>> On Wed, 28 Oct 2009, Edward Lam wrote:
>>>
>>>> I only looked at what caught my eye on the list. Bug 2001 seems  
>>>> like
>>>> important low hanging fruit to do before final release:
>>>>     http://bugzilla.maptools.org/show_bug.cgi?id=2001
>>>>
>>>>
>>> I agree that these issues should be avoided, but don't think that
>>> -fno-strict-aliasing is the answer since it surely makes the code
>>> slower.  I did fix many of the aliasing warnings.  The CVS HEAD  
>>> version
>>> only produces these from the library code:
>>> ...<snip>  ...
>>>
>> That's fine if someone has/will look at these to determine if they're
>> real problems. I haven't. :)
>>
>>
>>> Several utilities produce such warnings, and particularly  
>>> 'tiffcrop' in
>>> CVS HEAD spews lots of them.
>>>
>> It's probably easy to introduce unless we build with the extra
>> -Wstrict-aliasing=2 compiler?
>>
>>
>>> The libtiff from CVS branch-3-9 (which would be 3.9.2) produces no
>>> aliasing warnings from the library, and just a few warnings about
>>> uninitialized variables in some of the utilities.
>>>
>> Sorry, I had somehow mistakenly thought that we were looking at a 4.0
>> release. :embarrassed:
>>
>>
>>> Can you please re-check your builds with CVS libtiff and see if  
>>> you see
>>> similar results?
>>>
>> I'm not sure if this is directed to me in particular. I had not  
>> checked
>> in the first place since my usual development platform is on Win64. I
>> trust your results are correct. :)
>>
>> Regards,
>> -Edward
>>
>>
>>
>> ------------------------------
>>
>> Message: 8
>> Date: Thu, 29 Oct 2009 10:22:56 -0500 (CDT)
>> From: Bob Friesenhahn<bfriesen@simple.dallas.tx.us>
>> Subject: Re: [Tiff] Libtiff release soon, please advise
>> To: Edward Lam<edward@sidefx.com>
>> Cc: Tiff List<tiff@lists.maptools.org>
>> Message-ID:
>> 	<alpine.GSO.2.01.0910291017380.1964@freddy.simplesystems.org>
>> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>>
>> On Wed, 28 Oct 2009, Edward Lam wrote:
>>
>>
>>> It's probably easy to introduce unless we build with the extra
>>> -Wstrict-aliasing=2 compiler?
>>>
>> I am not familiar with that one yet.
>>
>>
>>>> The libtiff from CVS branch-3-9 (which would be 3.9.2) produces  
>>>> no aliasing
>>>> warnings from the library, and just a few warnings about  
>>>> uninitialized
>>>> variables in some of the utilities.
>>>>
>>> Sorry, I had somehow mistakenly thought that we were looking at a  
>>> 4.0
>>> release. :embarrassed:
>>>
>> To clarify, I expect to cut a release from both HEAD and branch-3-9,
>> but the HEAD release would be just another beta.  It is not fair  
>> doing
>> one without the other and they both include similar improvements.
>>
>>
>>> I'm not sure if this is directed to me in particular. I had not  
>>> checked in
>>> the first place since my usual development platform is on Win64.  
>>> I trust your
>>> results are correct. :)
>>>
>> I did see a couple of bug reports about warnings under Win64 and  
>> think
>> they are still open.  Since I don't have it, I don't test on it.
>>
>> Bob
>> --
>> Bob Friesenhahn
>> bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/ 
>> bfriesen/
>> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Tiff mailing list
>> Tiff@lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/tiff
>>
>> End of Tiff Digest, Vol 65, Issue 9
>> ***********************************
>>
>>
>>
> _______________________________________________
> Tiff mailing list: Tiff@lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/tiff
> http://www.remotesensing.org/libtiff/

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