Bug 2134 - TIFFClientOpen's mapproc's return value not clearly explained
: TIFFClientOpen's mapproc's return value not clearly explained
Status: RESOLVED LATER
: libtiff
default
: 3.9.0
: PC All
: P4 minor
: ---
Assigned To:
:
:
: migrated_to_gitlab
:
:
  Show dependency treegraph
 
Reported: 2009-12-22 13:31 by
Modified: 2019-10-01 14:19 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-12-22 13:31:45
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.
------- Comment #1 From 2019-10-01 14:19:21 -------
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.