libtiff 4.0.0beta3

[Frank Warmerdam-2]

Folks,

With Bob's help I have uploaded a snapshot of CVS head which I have
dubbed libtiff 4.0.0 beta3.

   http://download.osgeo.org/libtiff/tiff-4.0.0beta3.tar.gz
   http://download.osgeo.org/libtiff/tiff-4.0.0beta3.zip

I would appreciate folks trying this out and reporting outstanding issues
via bugzilla.  Ideally I'd like to prepare a libtiff 4.0.0 release candidate
within the next month.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
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@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Edward Lam]

Hi Frank,

I justed tested this with a build on WinXP x64. Things seem to work fine
with my own narrow regression tests.

The only warning I got while compiling was:

tif_dirinfo.c(508) : warning C4133: 'function' : incompatible types -
from 'size_t *' to 'unsigned int *'

Regards,
-Edward

Frank Warmerdam wrote:

> Folks,
>
> With Bob's help I have uploaded a snapshot of CVS head which I have
> dubbed libtiff 4.0.0 beta3.
>
>    http://download.osgeo.org/libtiff/tiff-4.0.0beta3.tar.gz
>    http://download.osgeo.org/libtiff/tiff-4.0.0beta3.zip
>
> I would appreciate folks trying this out and reporting outstanding issues
> via bugzilla.  Ideally I'd like to prepare a libtiff 4.0.0 release candidate
> within the next month.
>
> Best regards,

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

[Edward Lam]

Looks like I spoke too soon. I had previously only built libtiff with my
custom build process and did not go through the usual nmake.

I did a pass using the canonical build instructions for MSVC and got
some additional warnings similar to:

tif_lzw.c(389) : warning C4244: '+=' : conversion from 'tmsize_t' to
'long', possible loss of data
tif_lzw.c(606) : warning C4244: '+=' : conversion from 'tmsize_t' to
'long', possible loss of data
tif_lzw.c(715) : warning C4244: '=' : conversion from 'tmsize_t' to
'long', possible loss of data

As for the tools, tiffcrop fails to compile on Windows. stdint.h is not
available on Windows. I only took a quick look and I'm not sure if it's
necessary?

Here is the patch that I did to get it to compile on Windows:

============================================================
--- tiffcrop.c  2009-01-11 15:04:22.000000000 -0500
+++ ../../tiff-4.0.0beta3.new/tools/tiffcrop.c  2009-01-22
11:17:55.670500000 -0
500
@@ -117,7 +117,9 @@
  #include <stdio.h>
  #include <stdlib.h>
  #include <string.h>
+#if !defined(__WIN32__) && !defined(_MSC_VER)
  #include <stdint.h>
+#endif
  #include <math.h>
  #include <ctype.h>
  #include <limits.h>
@@ -130,6 +132,7 @@

  #ifndef HAVE_GETOPT
  extern int getopt(int, char**, char*);
+extern int optind;
  #endif

  #include "tiffio.h"
=============================================================

Regards,
-Edward

Edward Lam wrote:

> Hi Frank,
>
> I justed tested this with a build on WinXP x64. Things seem to work fine
> with my own narrow regression tests.
>
> The only warning I got while compiling was:
>
> tif_dirinfo.c(508) : warning C4133: 'function' : incompatible types -
> from 'size_t *' to 'unsigned int *'
>
> Regards,
> -Edward
>
> Frank Warmerdam wrote:
>> Folks,
>>
>> With Bob's help I have uploaded a snapshot of CVS head which I have
>> dubbed libtiff 4.0.0 beta3.
>>
>>    http://download.osgeo.org/libtiff/tiff-4.0.0beta3.tar.gz
>>    http://download.osgeo.org/libtiff/tiff-4.0.0beta3.zip
>>
>> I would appreciate folks trying this out and reporting outstanding issues
>> via bugzilla.  Ideally I'd like to prepare a libtiff 4.0.0 release candidate
>> within the next month.
>>
>> Best regards,
>
> _______________________________________________
> 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/

[Bob Friesenhahn]

On Thu, 22 Jan 2009, Edward Lam wrote:
>
> As for the tools, tiffcrop fails to compile on Windows. stdint.h is not
> available on Windows. I only took a quick look and I'm not sure if it's
> necessary?

It is an error for tiffcrop to be using stdint.h at all since stdint.h
is not portable, and facilities are already in place to make up for
it.  Libtiff should not require more than c'89.

>  #ifndef HAVE_GETOPT
>  extern int getopt(int, char**, char*);
> +extern int optind;
>  #endif

This little bit may be important to other platforms as well.

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/

[Bob Friesenhahn]

On Thu, 22 Jan 2009, Edward Lam wrote:

>
> I did a pass using the canonical build instructions for MSVC and got
> some additional warnings similar to:
>
> tif_lzw.c(389) : warning C4244: '+=' : conversion from 'tmsize_t' to
> 'long', possible loss of data
> tif_lzw.c(606) : warning C4244: '+=' : conversion from 'tmsize_t' to
> 'long', possible loss of data
> tif_lzw.c(715) : warning C4244: '=' : conversion from 'tmsize_t' to
> 'long', possible loss of data

This type of warning is quite worrysome.  For Windows builds, the
'long' type is always 32-bit whereas it is usually 64-bit on Unix
systems.  Undetected overflow will result in wrong processing, and may
represent an available security exploit.

Can you post the full list of such warnings?

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/

[Frank Warmerdam-2]

Edward Lam wrote:

> Looks like I spoke too soon. I had previously only built libtiff with my
> custom build process and did not go through the usual nmake.
>
> I did a pass using the canonical build instructions for MSVC and got
> some additional warnings similar to:
>
> tif_lzw.c(389) : warning C4244: '+=' : conversion from 'tmsize_t' to
> 'long', possible loss of data
> tif_lzw.c(606) : warning C4244: '+=' : conversion from 'tmsize_t' to
> 'long', possible loss of data
> tif_lzw.c(715) : warning C4244: '=' : conversion from 'tmsize_t' to
> 'long', possible loss of data

Edward,

I have been unable to reproduce these warnings with MSVC 7.1 (studio 2003).
I used /Ox /MD /EHsc /W3 options.  What version of MSVC and what options
did you use?  A full list of these warnings (at least within the library
itself) would be appreciated.

These particular ones are not actually significant on review, but others
might well be and in any event we would like warning free builds.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
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@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Edward Lam]

Bob Friesenhahn wrote:
>>  #ifndef HAVE_GETOPT
>>  extern int getopt(int, char**, char*);
>> +extern int optind;
>>  #endif
>
> This little bit may be important to other platforms as well.

Actually, it would be good if we had a common header that all the
libtiff tools used that had this. As it stands right now, various tools
use getopt without even declaring it, relying on a default generated
function prototype. (See build3.txt in my previous email).

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

[Frank Warmerdam-2]

Edward Lam wrote:

> Bob Friesenhahn wrote:
>>>  #ifndef HAVE_GETOPT
>>>  extern int getopt(int, char**, char*);
>>> +extern int optind;
>>>  #endif
>>
>> This little bit may be important to other platforms as well.
>
> Actually, it would be good if we had a common header that all the
> libtiff tools used that had this. As it stands right now, various tools
> use getopt without even declaring it, relying on a default generated
> function prototype. (See build3.txt in my previous email).

Edward,

Oddly, i'm on it. I'm commiting a libport.h that will have some of these
definitions in it.  For now I'm only using this on windows (Makefile.vc).
I'm really not too clear how all this libport magic works on unix.

/me aims for warning free builds...

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
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@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Bob Friesenhahn]

On Thu, 22 Jan 2009, Frank Warmerdam wrote:

> Oddly, i'm on it. I'm commiting a libport.h that will have some of these
> definitions in it.  For now I'm only using this on windows (Makefile.vc).
> I'm really not too clear how all this libport magic works on unix.

It seems that the libport magic is based on autoconf magic which
automatically enables building of correctly source files which provide
implementations for missing functions.

> /me aims for warning free builds...

Hopefully based on correctness rather than excessive casts.

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/

[Frank Warmerdam-2]

Bob Friesenhahn wrote:

> On Thu, 22 Jan 2009, Frank Warmerdam wrote:
>
>> Oddly, i'm on it. I'm commiting a libport.h that will have some of these
>> definitions in it.  For now I'm only using this on windows (Makefile.vc).
>> I'm really not too clear how all this libport magic works on unix.
>
> It seems that the libport magic is based on autoconf magic which
> automatically enables building of correctly source files which provide
> implementations for missing functions.
>
>> /me aims for warning free builds...
>
> Hopefully based on correctness rather than excessive casts.

Bob,

I try to consider the appropriateness of the casts before adding them,
but I would prefer to hide some warnings that ought to be considered
and get "clean" so new warnings get seriously in preference to the
current situation (in tools at least) where I've given up on the warnings
seem they are legion.

I did try to ignore the situation for a long time in the hope that others
would fix it properly!

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
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@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Bob Friesenhahn]

On Thu, 22 Jan 2009, Frank Warmerdam wrote:
>
> I try to consider the appropriateness of the casts before adding them,
> but I would prefer to hide some warnings that ought to be considered
> and get "clean" so new warnings get seriously in preference to the
> current situation (in tools at least) where I've given up on the warnings
> seem they are legion.

Sometimes changing a type will eliminate the warning.  For example,
the 'long' could be changed to the TIFF 64-bit size type.  Or if
64-bits was excessive in the first place, perhaps it can be carefully
reduced to 32 bits much sooner so that much of the code does not need
to worry about these large types.

> I did try to ignore the situation for a long time in the hope that
> others would fix it properly!

Hopefully you noticed that my activities a week or two ago eliminated
a large number of warnings (while actually removing many casts).  Of
course, removal of the core dumps was my primary concern.

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/

[Edward Lam]

Bob Friesenhahn wrote:
> On Thu, 22 Jan 2009, Frank Warmerdam wrote:
>
>> Oddly, i'm on it. I'm commiting a libport.h that will have some of these
>> definitions in it.  For now I'm only using this on windows (Makefile.vc).
>> I'm really not too clear how all this libport magic works on unix.
>
> It seems that the libport magic is based on autoconf magic which
> automatically enables building of correctly source files which provide
> implementations for missing functions.

If this is the case, then perhaps the right place to put the libport
definitions are in tif_config.h-vms, tif_config.vc.h, and
tif_config.wince.h (as appropriate).

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

[Jay Berkenbilt-2]

So, if all goes according to plan, debian 5.0 should release this
weekend, and the long freeze will be over.  I could upload 3.9.0 if
it's going to be released (since all the ABI compatibility issues have
been resolved), and I can upload 4.0.0.beta3 or a release candidate to
experimental and ask people to start testing it.  (I could have done
that anyway, actually, but I doubt very many people would have tested
it.)  Once the actual 4.0.0 is released, I'll work with the release
team on the transition.  If 4.0.0 is getting really close, I probably
won't bother upload 3.9.0.  So, is there any expectation of a 3.9.0
release?

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

[Bob Friesenhahn]

On Sat, 14 Feb 2009, Jay Berkenbilt wrote:

> If 4.0.0 is getting really close, I probably
> won't bother upload 3.9.0.  So, is there any expectation of a 3.9.0
> release?

I believe that 3.9.0 can be (is) very close to release.

4.0.0 could be close to release but there are bad things about it
which should be corrected.  For example, the API documentation no
longer matches the actual API definition since typedefs were removed
from the function definitions.  Either the APIs should be updated so
that they are similar to the documentation, or the documentation needs
to be updated to match the APIs.  My preference is that the APIs
should match the previously published documentation to the maximum
extent possible since then new code will still work with libtiff
3.X.X, which will surely continue to be used for many more years.

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/

[Jay Berkenbilt-2]

Bob Friesenhahn <bfriesen@...> wrote:

> On Sat, 14 Feb 2009, Jay Berkenbilt wrote:
>
>> If 4.0.0 is getting really close, I probably won't bother upload
>> 3.9.0.  So, is there any expectation of a 3.9.0 release?
>
> I believe that 3.9.0 can be (is) very close to release.

There's a debian user who is running into some problems with tiff
3.8.2 that are fixed in the 3.9.0 beta.  I'm thinking about just
rolling by own 3.9.0 beta plus release by taking the latest beta and
pulling in patches from CVS to make it binary compatibility, and then
uploading at something like 3.9.0.beta+cvs...Should I go ahead with
this plan?  I'm not sure exactly what is involved in getting 3.9.0
released or whether anyone has time to do it.  My time is limited, but
if there's a way I can help, let me know.

--
Jay Berkenbilt <ejb@...>
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Jay Berkenbilt-2]

Just so "upstream" (from my debian perspective) tiff people know, I've
prepared a fake release of libtiff based on the branch-3-9 branch in CVS
and called it "3.9.0beta+deb1".  I basically followed the release
instructions minus creating a new file in the html directory, verified
source and binary compatibility with 3.8.2, and uploaded it to debian's
experimental distribution.  There is enough interest in something newer
than 3.8.2 in debian that, unless there are any major objections either
from tiff maintainers or debian developers, I plan to make that be the
standard version in debian.  Once this goes through, I will feel free to
upload a beta of 4.0.0 to debian's experimental.  I haven't been doing
that up to now because I haven't wanted to lock myself out of being able
to upload something based on 3.9.  So this is just an FYI to tiff
maintainers that debian may soon have an unofficial release of libtiff
in it, based on my belief (from discussions on this list) that the
current 3.9 branch is probably pretty much ready to go and certainly
better than 3.8.2.  It's not too late to stop me though. :-)

--
Jay Berkenbilt <ejb@...>
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Bob Friesenhahn]

I will be happy to help with the preparation of a formal release but
as far as I am aware, the keeper of the keys is Frank Warmerdam.  I
could create a release tarball but only (?) Frank can put it where it
counts.

You are surely correct that the current 3.9 branch is more robust and
less buggy than 3.8.2, but keep in mind that libtiff developers have
been personally using 4.0 development sources for well over a year,
and not the 3.9.X stuff.

Bob

On Wed, 19 Aug 2009, Jay Berkenbilt wrote:

>
> Just so "upstream" (from my debian perspective) tiff people know, I've
> prepared a fake release of libtiff based on the branch-3-9 branch in CVS
> and called it "3.9.0beta+deb1".  I basically followed the release
> instructions minus creating a new file in the html directory, verified
> source and binary compatibility with 3.8.2, and uploaded it to debian's
> experimental distribution.  There is enough interest in something newer
> than 3.8.2 in debian that, unless there are any major objections either
> from tiff maintainers or debian developers, I plan to make that be the
> standard version in debian.  Once this goes through, I will feel free to
> upload a beta of 4.0.0 to debian's experimental.  I haven't been doing
> that up to now because I haven't wanted to lock myself out of being able
> to upload something based on 3.9.  So this is just an FYI to tiff
> maintainers that debian may soon have an unofficial release of libtiff
> in it, based on my belief (from discussions on this list) that the
> current 3.9 branch is probably pretty much ready to go and certainly
> better than 3.8.2.  It's not too late to stop me though. :-)
>
> --
> Jay Berkenbilt <ejb@...>
> _______________________________________________
> Tiff mailing list: Tiff@...
> http://lists.maptools.org/mailman/listinfo/tiff
> http://www.remotesensing.org/libtiff/
>

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

[Frank Warmerdam-2]

Bob Friesenhahn wrote:
> I will be happy to help with the preparation of a formal release but
> as far as I am aware, the keeper of the keys is Frank Warmerdam.  I
> could create a release tarball but only (?) Frank can put it where it
> counts.
>
> You are surely correct that the current 3.9 branch is more robust and
> less buggy than 3.8.2, but keep in mind that libtiff developers have
> been personally using 4.0 development sources for well over a year,
> and not the 3.9.X stuff.

Bob,

I'm happy to put up a new release. I've felt helpless because I don't
have the right versions of some of the autotools stuff.  I'm also happy
to provide a shell account on the libtiff file server to any of the
libtiff maintainers.  Just create an account at:

   https://www.osgeo.org/cgi-bin/ldap_create_user.py

and let me know what the userid is.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
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@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Jay Berkenbilt-2]

Frank Warmerdam <warmerdam@...> wrote:

> Folks,
>
> With Bob's help I have uploaded a snapshot of CVS head which I have
> dubbed libtiff 4.0.0 beta3.
>
>    http://download.osgeo.org/libtiff/tiff-4.0.0beta3.tar.gz
>    http://download.osgeo.org/libtiff/tiff-4.0.0beta3.zip
>
> I would appreciate folks trying this out and reporting outstanding issues
> via bugzilla.  Ideally I'd like to prepare a libtiff 4.0.0 release candidate
> within the next month.

Now that 3.9.0 is out, I'd like to go ahead and upload 4.0.0 beta
something to debian's experimental distribution.  Should I take this
7-month old beta release, or can we get a new 4.0.0 beta?  Either way is
fine.  In this case, I may just prepare a 4.0.0 beta 3 upload for
debian's experimental while I'm waiting anyway, but I won't try to roll
my own from the trunk.

Once 4.0.0 is released, I do intend to upload it to debian, but since it
is a known ABI change, it will have to be coordinated with the debian
release team and therefore probably won't happen that quickly.  But I
can put it in experimental any time.

--
Jay Berkenbilt <ejb@...>
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Frank Warmerdam-2]

Jay Berkenbilt wrote:

> Frank Warmerdam <warmerdam@...> wrote:
>
>> Folks,
>>
>> With Bob's help I have uploaded a snapshot of CVS head which I have
>> dubbed libtiff 4.0.0 beta3.
>>
>>    http://download.osgeo.org/libtiff/tiff-4.0.0beta3.tar.gz
>>    http://download.osgeo.org/libtiff/tiff-4.0.0beta3.zip
>>
>> I would appreciate folks trying this out and reporting outstanding issues
>> via bugzilla.  Ideally I'd like to prepare a libtiff 4.0.0 release candidate
>> within the next month.
>
> Now that 3.9.0 is out, I'd like to go ahead and upload 4.0.0 beta
> something to debian's experimental distribution.  Should I take this
> 7-month old beta release, or can we get a new 4.0.0 beta?  Either way is
> fine.  In this case, I may just prepare a 4.0.0 beta 3 upload for
> debian's experimental while I'm waiting anyway, but I won't try to roll
> my own from the trunk.

Jay,

There have been noteworthy fixes since the last beta.

Bob, would you be willing to roll out a 4.0.0 beta?

> Once 4.0.0 is released, I do intend to upload it to debian, but since it
> is a known ABI change, it will have to be coordinated with the debian
> release team and therefore probably won't happen that quickly.  But I
> can put it in experimental any time.
>


--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
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@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/