- 2019.04.23 21:04 "Re: [Tiff] TIFFWriteScanLine - buffers to RAM before flushing to disc?", by Kemp Watson
-
2019.04.23 21:24 "Re: [Tiff] TIFFWriteScanLine - buffers to RAM before flushing to disc?", by Bob Friesenhahn
- 2019.04.24 11:28 "Re: [Tiff] TIFFWriteScanLine - buffers to RAM before flushing to disc?", by Paul Hemmer
- 2019.06.20 15:31 "Re: [Tiff] TIFFFdOpen crash on Windows 64bit", by ZdPo Ster
- 2019.04.24 15:51 "Re: [Tiff] TIFFWriteScanLine - buffers to RAM before flushing to disc?", by Paul Hemmer
2019.06.20 12:43 "Re: [Tiff] TIFFFdOpen crash on Windows 64bit", by Bob Friesenhahn
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[1] 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)[3],
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 perfectly.
Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt