You need to log in before you can comment on or make changes to this bug.
When using TIFFClientOpen, you have to provide a TIFFMapFileProc mapproc. I could not find information on what mapproc should return. I think, people may use contrib/mfs/mfs_file.c as an example. In mfs_file.c, the function mfs_map() is used as mapproc. mfs_map() returns -1 in case of error and 0 in case of success. This seems to be the wrong way around, as explained below: In libtiff/tif_open.c, one can find the lines: if ((tif->tif_flags & TIFF_MAPPED) && !TIFFMapFileContents(...)) tif->tif_flags &= ~TIFF_MAPPED; (In libtiff/tiffiop.h, TIFFMapFileContents is defined to essentially be tif_mapproc, which in turn has been set in TIFFClientOpen to be the supplied TIFFMapFileProc mapproc.) In the source code lines above, memory mapping will only be used if TIFFMapFileContents returns an int that corresponds to TRUE. This means: When in case of error mfs_map() returns -1, this will be interpreted as TRUE and memory mapping may be used. When after successfully setting address and length mfs_map() returns 0, this will be interpreted as FALSE and memory mapping will not be used. I checked that when mapproc returns 0, seekproc and readproc will still be used (e.g. by TIFFReadEncodedStrip), and when mapproc returns 1, memory mapping will be used instead. I hope I did not make a mistake, Thanks.
Bugzilla is no longer used for tracking libtiff issues. Remaining open tickets, such as this one, have been migrated to the libtiff GitLab instance at https://gitlab.com/libtiff/libtiff/issues . The migrated tickets have their summary prefixed with [BZ#XXXX] where XXXX is the initial Bugzilla issue number.