- 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:01 "Re: [Tiff] TIFFFdOpen crash on Windows 64bit", by Edward Lam
Hi,
On 6/20/2019 3:38 AM, ZdPo Ster wrote:
> IMO this is relevant to Bug 1941 - Win64 problem with tif_win32.c's TIFFOpen()
use of HANDLE (w/patch)[3],
Unfortunately " Bugzilla has suffered an internal error", so new account can not be created e.g. I can not comment it there too.
I'm being lazy here but are you saying that the upper 32-bits returned by _get_osfhandle() in your test code is NOT zero?
-Edward
Does anybody has the same experience or is there workaround for this?
I use the latest code[4] build with cmake and clang (version 9.0.0 (trunk) Target: x86_64-pc-windows-msvc).
[1] https://gitlab.freedesktop.org/poppler/poppler/blob/master/goo/TiffWriter.cc#L167 [2] https://gitlab.freedesktop.org/poppler/poppler/blob/master/utils/pdftoppm.cc [3] http://bugzilla.maptools.org/show_bug.cgi?id=1941 [4] https://gitlab.com/libtiff/libtiff
> _______________________________________________
> Tiff mailing list
> Tiff@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/tiff
>