2019.06.20 15:31 "Re: [Tiff] TIFFFdOpen crash on Windows 64bit", by ZdPo Ster
Thanks for reply. Finally it seems I found solution ;-): Problem is present in version 4.0.10, but it is fixed in current code - I guess commit 59eb3517 fixed it. I was sure I was linking my test code to gitlab version, but it turn out I was wrong.
Unfortunately also gitlab code (TIFFGetVersion()) returns "LIBTIFF, Version 4.0.10". Maybe LIBTIFF, Version 4.0.11dev or something like that (git describe --abbrev=4) would help...
If I understand it correctly released 4.0.10 version used tif_unix.c in windows cmake build => it does no work for me. Current code use tif_win32.c and it works.
 https://download.osgeo.org/libtiff/tiff-4.0.10.zip  https://gitlab.com/libtiff/libtiff/commit/59eb35172f8dc9a46469ad0e4877f9c88ab796cd
On Thu, 20 Jun 2019 at 14:43, Bob Friesenhahn <email@example.com> wrote:
> On Thu, 20 Jun 2019, ZdPo Ster wrote:
> > Hello,
> > When I try to use TIFFFdOpen on Windows 10 64bit - but it crash. In
> > attachment there is my testing code. I found this problem when I was > > testing poppler utility pdftoppm (to convert pdf to tif).
> > IMO this is relevant to Bug 1941 - Win64 problem with tif_win32.c's
> > TIFFOpen() use of HANDLE (w/patch),
> I should point out that it is possible to use tif_unix.c under Windows > as well. It appears that your code assumes use of tif_win32.c. It
> may well be that tif_unix.c was used in the libtiff build. I see that > the Autoconf configure script offers the option --disable-win32-io to
> disable use of Windows I/O but it is possible that it might also be > disabled by a test (e.g. if it thought that the host_os is Cygwin).
> Regardless, usually one should check for errors at each step, which
> your code does not do.
> It is safer to use TIFFClientOpen(), but then I/O wrapper functions > need to be supplied, and this can take a few tries to implement
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt