AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2016.11.11 14:03 "[Tiff] Global variables in LibTIFF", by Paavo Helde
2016.11.11 14:39 "Re: [Tiff] Global variables in LibTIFF", by Bob Friesenhahn
2016.11.11 14:47 "Re: [Tiff] Global variables in LibTIFF", by Olivier Paquet
2016.11.11 21:32 "Re: [Tiff] Global variables in LibTIFF", by Even Rouault
2016.11.11 22:22 "Re: [Tiff] Global variables in LibTIFF", by Bob Friesenhahn
2016.11.12 00:24 "Re: [Tiff] Global variables in LibTIFF", by Yakov Galka
2016.11.12 14:56 "Re: [Tiff] Global variables in LibTIFF", by Bob Friesenhahn
2016.11.12 16:04 "Re: [Tiff] Global variables in LibTIFF", by Yakov Galka
2016.11.16 12:04 "Re: [Tiff] Global variables in LibTIFF", by Gerben Vos
2016.11.16 12:29 "Re: [Tiff] Global variables in LibTIFF", by Yakov Galka
2016.11.12 20:40 "Re: [Tiff] Global variables in LibTIFF", by Paavo Helde

2016.11.12 16:04 "Re: [Tiff] Global variables in LibTIFF", by Yakov Galka

On Sat, Nov 12, 2016 at 4:56 PM, Bob Friesenhahn <
bfriesen@simple.dallas.tx.us> wrote:

You must be referring to this statement by Edward Lam (not by me):

Oh, sorry about that, I don't really remember :)

We need to take care that libtiff API improvements don't break the ABI since existing users are depending on libtiff releases (when they occur) to fix libtiff security issues and bugs without needing to rebuild the "world", and (particularly) without needing to patch packages using libtiff so that they work again.

API improvements should be layered on top of, or adjacent to, the existing API, acting as alternatives without breaking the existing API/ABI. Changes made for libtiff 4.X (e.g. hiding implementation structures) make this possible whereas before it was clearly impossible.

Libtiff is 28 years old already and we can not afford to upset the substantial body of existing software.

This is all obvious, and if you looked at my patches you've seen that I
introduced the new functionality without breaking the current ABI. The
problems I'm talking about is the (undocumented) API *behavior* wrt the
interplay of some of the library features.

For example:

    int fd = ...;
    TIFF *tiff0 = TIFFOpen("0.tiff", "r");
    TIFFSetClientdata(tiff0, thandle_t(fd));

TIFFRead(...); // <<<<<<<<<<<<<< This fails on today's libTIFF!

Another example:

    TIFF *tiff0 = TIFFOpen("0.tiff", "r");
    int fd = open("1.tiff", O_RDONLY);
    TIFF *tiff1 = TIFFClientOpen("1.tiff", "r", thandle_t(fd),

        TIFFGetReadProc(tiff0), TIFFGetWriteProc(tiff0),
        TIFFGetSeekProc(tiff0), TIFFGetCloseProc(tiff0),
        TIFFGetSizeProc(tiff0), TIFFGetMapFileProc(tiff0),
        TIFFGetUnmapFileProc(tiff0)

); // <<<<<<<<<<<<<<<<<<<<<<<<< Should this work?

Specifically, current libTIFF has the following problems (relevant to this
discussion):

=> We need to either free-up tif_clientdata for their exclusive use or to introduce tif_clientdataV2.

! Note that we already have tif_fd, though it's useless on Windows!

* i/o callbacks receive a thandle_t rather than the TIFF* structure.

=> Users implementing i/o callbacks cannot access the properties of the TIFF*, like mode or filename for the purpose of error reporting.

Both examples above will work without recompilation with my patch. However,
now users will be able to use the new interface as follows:

TIFF *tiff = TIFFCreateNamedContext("0.tiff");

TIFFSetClientdata(tiff, my_error_log_pointer);

TIFFSetSetErrorProcs(tiff, my_error_proc, my_warning_proc);

_TIFFOpen(tiff, "0.tiff", "r"); // should be TIFFOpenV2

--

Yakov Galka
http://stannum.co.il/