2009.10.29 18:21 "Re: [Tiff] Tiff Digest, Vol 65, Issue 9", by Toby Thain

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.

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

> 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

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.

>> 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

> End of Tiff Digest, Vol 65, Issue 9
> ***********************************
>
>
>