- 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.11 21:32 "Re: [Tiff] Global variables in LibTIFF", by Even Rouault
2016.11.12 00:24 "Re: [Tiff] Global variables in LibTIFF", by Yakov Galka
Hey all,
Following our discussion of this issue a few month ago I actually went implementing it. You can look at the patches based on my current code on the following links. I've split it into two patches for easier review: one of the manual edits and one of the autoreplace of the TIFFError/Warning calls:
http://stannum.co.il/data/tiff-changes.diff
http://stannum.co.il/data/tiff-autorep.diff
I don't remember the exact state of them at the moment, but here is what I can remember off the top of my head:
- I tried to solve the problem of error/warning being global callbacks.
- While doing this I encountered other bad-designed aspects of the library. So trying to make a uniform interface for all callbacks I modified a bit extra of the functionality.
- Yet I tried not to break backward compatibility with 'typical' code. Some code that assumes the interplay of clientdata, file descriptors and the read/write/seek callbacks might break.
- I tried to prevent combinatorial explosion by introducing a two step TIFF creation: first one allocates the structure, sets the relevant parameters, then issues the actual Open* call. That state separation actually happened to be useful in fax2tiff in the "FakeInput" TIFF.
- AFAIR I dug some old cases wrt. using Windows HANDLEs instead file descriptors and 64-bit issues with those, and started thinking of how to fix the library to correctly support those. This is where I stopped working on it.
- THESE AREN'T FINISHED MODIFICATIONS. Though at some point I ran it against the tests and everything passed.
- I stopped working on it because:
- I thought that the redesign is too big so you might not be interested to merge it.
- Despite all the efforts some backward compatibility wrt some corner cases will break anyways. Even though I estimate it to be less than 2% of the code out there.
- Bug 2575 that I found during the refactoring was not addressed...
- and at the same time Bob referred to libtiff as a 'dead horse' on this mailing list...
- so...
- You are welcome to look at it. If you need a detailed documentation of all re-design decisions and considerations then ask for it, I had a draft somewhere. If you think that this is the right direction then I can find the time to finish it, with your cooperation on weighting backward compatibility and new interface issues.
----------------------
Regarding the patch proposed in Bug 2255: I've looked at it at the time, but I actually consider it being NOT A SOLUTION:
- First it is not backward compatible at all. Making it backward compatible means one needs to duplicate ALL the interface (one with the TIFFApplication and one without).
- It does not solve the problem of retrieving a custom per-tiff userdata from the error handlers, which in my case (of an error-checked libtiff c++ wrapper at my work) does not help.
----------------------
<http://bugzilla.maptools.org/show_bug.cgi?id=2255> I hope you find this useful.
Cheers,
Yakov Galka
http://stannum.co.il/