Re: Tiff Digest, Vol 65, Issue 9
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: Tiff Digest, Vol 65, Issue 9
by Bob Friesenhahn
::
Rate this Message:
On Thu, 29 Oct 2009, 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 Drive safe! > 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. Aha! It turns out that one build was using -O2 while the other was using -O. With -O2 I see similar warnings in branch-3-9. The good news is that there are still only two such warnings in the library code, which should require identical fixes. The tiffcrop utility warnings may take some time to sort out, but it seems that if the library builds clean and works, that it is ok to produce a new distribution. Bob === Bob Friesenhahn bfriesen@..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
Re: Tiff Digest, Vol 65, Issue 9
by Toby Thain-2
::
Rate this Message:
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@... wrote: >> Send Tiff mailing list submissions to >> tiff@... >> >> 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@... >> >> You can reach the person managing the list at >> tiff-owner@... >> >> 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@...> >> Subject: Re: [Tiff] extending tags in "a"ppend mode? >> To: tiff@... >> Message-ID:<20091028184123.aef7f387.pullmoll@...> >> Content-Type: text/plain; charset=US-ASCII >> >> On Wed, 28 Oct 2009 17:28:34 +0100 >> Juergen Buchmueller<pullmoll@...> 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@...> >> Subject: Re: [Tiff] Number of images in a multi-tiff file? >> To: Frank Warmerdam<warmerdam@...> >> Cc: tiff@... >> Message-ID:<4AE883A1.4080908@...> >> 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@...> >> Subject: Re: [Tiff] extending tags in "a"ppend mode? - solved >> To: tiff@... >> Message-ID:<20091028184630.26999537.pullmoll@...> >> 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@...> >> Subject: [Tiff] Libtiff release soon, please advise >> To: Tiff List<tiff@...> >> Message-ID: >> <alpine.GSO.2.01.0910281737540.1964@...> >> 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@..., 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@...> >> Subject: Re: [Tiff] Libtiff release soon, please advise >> To: Bob Friesenhahn<bfriesen@...> >> Cc: Tiff List<tiff@...> >> Message-ID:<4AE8FD78.1050704@...> >> 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@...> >> Subject: Re: [Tiff] Libtiff release soon, please advise >> To: Edward Lam<edward@...> >> Cc: Tiff List<tiff@...> >> Message-ID: >> <alpine.GSO.2.01.0910282139070.1964@...> >> 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@..., 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@...> >> Subject: Re: [Tiff] Libtiff release soon, please advise >> To: Bob Friesenhahn<bfriesen@...> >> Cc: Tiff List<tiff@...> >> Message-ID:<4AE91205.2050407@...> >> 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@...> >> Subject: Re: [Tiff] Libtiff release soon, please advise >> To: Edward Lam<edward@...> >> Cc: Tiff List<tiff@...> >> Message-ID: >> <alpine.GSO.2.01.0910291017380.1964@...> >> 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@..., http://www.simplesystems.org/users/ >> bfriesen/ >> GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ >> >> >> ------------------------------ >> >> _______________________________________________ >> Tiff mailing list >> Tiff@... >> http://lists.maptools.org/mailman/listinfo/tiff >> >> End of Tiff Digest, Vol 65, Issue 9 >> *********************************** >> >> >> > _______________________________________________ > Tiff mailing list: Tiff@... > http://lists.maptools.org/mailman/listinfo/tiff > http://www.remotesensing.org/libtiff/ _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
Tiffcrop warnings
by Richard Nolde-2
::
Rate this Message:
On 10/29/2009 12:08 PM, Bob Friesenhahn wrote: > Aha! It turns out that one build was using -O2 while the other was > using -O. With -O2 I see similar warnings in branch-3-9. The good > news is that there are still only two such warnings in the library > code, which should require identical fixes. > > The tiffcrop utility warnings may take some time to sort out, but it > seems that if the library builds clean and works, that it is ok to > produce a new distribution. > I have a clean compile with tiffcrop updated from CVS Head and patched with new code based on Toby's suggestion. I will test on Friday and advise so we can get tiffcrop into the new release warning free. _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
Re: Tiffcrop warnings
by Edward Lam
::
Rate this Message:
On Thu, October 29, 2009 23:18, Richard Nolde wrote:
> I have a clean compile with tiffcrop updated from CVS Head and patched > with new code based on Toby's suggestion. I will test on Friday and > advise so we can get tiffcrop into the new release warning free. I just compiled libtiff CVS HEAD and run into an error compiling tiff_crop.c. On Windows, optind must be explicitly declared as extern. Here is the patch I applied in order for it to compile on Windows: ----------8<------------------------------------------------------------ diff -u -p -r1.14 tiffcrop.c --- tiffcrop.c 24 Sep 2009 21:57:11 -0000 1.14 +++ tiffcrop.c 1 Nov 2009 18:48:36 -0000 @@ -2084,6 +2084,7 @@ update_output_file (TIFF **tiffout, char int main(int argc, char* argv[]) { + extern int optind; uint16 defconfig = (uint16) -1; uint16 deffillorder = 0; uint32 deftilewidth = (uint32) 0; ---------->8------------------------------------------------------------ Regards, -Edward _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
Re: Tiffcrop warnings
by Richard Nolde-2
::
Rate this Message:
Edward,
I've added your patch to my working copy and will upload the latest code for Bob to commit to CVS when I finish testing tomorrow. With Bob's most recent patch to tif_dirwrite.c and my latest code based on Toby's suggestions, albeit with the endian options reversed, I get no compile warnings and the float tigers smile with the rest of them. What is the status of the following define on Windows? I assume you are not using Gcc under Mingw32 or such. #ifndef HAVE_GETOPT extern int getopt(int, char**, char*); #endif It doesn't cause a problem for me with GCC on Linux whether or not optind is declared external. Thanks, Richard On 11/01/2009 11:49 AM, Edward Lam wrote: > On Thu, October 29, 2009 23:18, Richard Nolde wrote: > >> I have a clean compile with tiffcrop updated from CVS Head and patched >> with new code based on Toby's suggestion. I will test on Friday and >> advise so we can get tiffcrop into the new release warning free. >> > I just compiled libtiff CVS HEAD and run into an error compiling > tiff_crop.c. On Windows, optind must be explicitly declared as extern. > Here is the patch I applied in order for it to compile on Windows: > > ----------8<------------------------------------------------------------ > diff -u -p -r1.14 tiffcrop.c > --- tiffcrop.c 24 Sep 2009 21:57:11 -0000 1.14 > +++ tiffcrop.c 1 Nov 2009 18:48:36 -0000 > @@ -2084,6 +2084,7 @@ update_output_file (TIFF **tiffout, char > int > main(int argc, char* argv[]) > { > + extern int optind; > uint16 defconfig = (uint16) -1; > uint16 deffillorder = 0; > uint32 deftilewidth = (uint32) 0; > ---------->8------------------------------------------------------------ > > Regards, > -Edward > > > Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
Re: Tiffcrop warnings
by Edward Lam
::
Rate this Message:
Richard Nolde wrote:
> It doesn't cause a problem for me with GCC on Linux whether or not > optind is declared external. According to opengroup.org, getopt()/optind are available via unistd.h which most of the tool sources include. That's why it compiles for you without the declarations. :) > What is the status of the following define [HAVE_GETOPT] on Windows? I assume you are > not using Gcc under Mingw32 or such. That is correct, I'm compiling using Visual Studio 2005 (64-bit). Note that port/libport.h defines HAVE_GETOPT for builds that use libport (MSVC does). This is defined in tools/Makefile.vc. You bring up a good point. It might be better if added "extern int optind" to port/libport.h instead. Ah, but tiffcrop.c (unlike most other tools) is missing an include to "libport.h". So there are two changes to be made if we go with this approach: - Add "extern int optind" to port/libport.h - And then in tiffcrop.c: -#ifndef HAVE_GETOPT -extern int getopt(int, char**, char*); +#ifdef NEED_LIBPORT +# include "libport.h" #endif What this approach will NOT fix though are platforms that don't use libport AND do not declare getopt()/optind in unistd.h. Not sure which Unix platforms don't have unistd.h with getopt()/optind though. :) -Edward _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
Re: Tiffcrop warnings
by Bob Friesenhahn
::
Rate this Message:
On Sun, 1 Nov 2009, Edward Lam wrote:
> > What this approach will NOT fix though are platforms that don't use libport > AND do not declare getopt()/optind in unistd.h. Not sure which Unix platforms > don't have unistd.h with getopt()/optind though. :) These extern declarations should be safe for any unixish 'getopt': extern char *optarg; extern int optind, opterr, optopt; Older Unix standards specified including <stdio.h> rather than <unistd.h>. It does seem like a good idea to add these missing extern statements to port/libport.h. Bob -- Bob Friesenhahn bfriesen@..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
Re: Tiffcrop warnings
by Juergen Buchmueller
::
Rate this Message:
On Sun, 01 Nov 2009 22:30:34 -0500
Edward Lam <edward@...> wrote: > Not sure which Unix platforms don't have unistd.h with > getopt()/optind though. :) FWIW here's the condition for NetBSD when to include the declarations in unistd.h /* * IEEE Std 1003.2-92, adopted in X/Open Portability Guide * Issue 4 and later */ #if (_POSIX_C_SOURCE - 0) >= 2 || defined(_XOPEN_SOURCE) || \ defined(_NETBSD_SOURCE) int getopt(int, char * const [], const char *); extern char *optarg; /* getopt(3) external variables */ extern int opterr; extern int optind; extern int optopt; #endif So it looks like you'll have to define _POSIX_C_SOURCE=2 or _XOPEN_SOURCE to get the defines. Juergen _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
| Free embeddable forum powered by Nabble | Forum Help |
