AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2013.05.21 10:32 "[Tiff] memory management function calls", by Chris Liddell
2013.05.21 14:11 "Re: [Tiff] memory management function calls", by Bob Friesenhahn
2013.05.21 15:11 "Re: [Tiff] memory management function calls", by Chris Liddell
2013.05.21 15:18 "Re: [Tiff] memory management function calls", by Bob Friesenhahn
2013.05.21 15:32 "Re: [Tiff] memory management function calls", by Chris Liddell
2013.05.21 15:38 "Re: [Tiff] memory management function calls", by Bob Friesenhahn
2013.05.21 17:21 "Re: [Tiff] memory management function calls", by Joris Van Damme
2013.05.21 17:28 "Re: [Tiff] memory management function calls", by Chris Liddell

2013.05.21 17:28 "Re: [Tiff] memory management function calls", by Chris Liddell

On Tue, 21 May 2013 19:21:41 +0200

Yes, but then standard malloc/realloc/free type functions can not

be specified directly. Special wrapper functions would need to be

added in order to support passing (and ignoring) the context

> >> before calling such functions.

Sure, so the function pointer types for the callbacks would have

> some kind of context pointer parameter

I've had the same problem when I added the context parameter to warning/error handler callbacks.

My solution was to support two sets of callbacks. One was the traditional set, without the context cookie parameter, the other was the new set with the additional parameter. The single point in the LibTiff library where the callback is actually called, it used the new callback with additional parameter if that callback is set. Otherwise, it calls the traditional handler without the additional context.

This way both needs are satisfied, people who require a context parameter set the new set of callbacks, people who require existing code to remain working without code change automatically stick with the old callbacks. It's a bit crufty and far fetched, but it does solve the problem. The only real disadvantage is that people hardly notice the option of using the new callbacks, so they kind of get forgotten and they may not work anymore a couple of versions down the line.

FWIW, Ghostscript now uses those callbacks, so thank you! And we, at least, are testing them regularly.

In the case of memory management callbacks, since I don't have to worry about old API callbacks, I'm inclined to add just one set, and let those who don't need the context just ignore the parameter.

Chris