2013.05.21 15:11 "Re: [Tiff] memory management function calls", by Chris Liddell

On Tue, 21 May 2013 09:11:40 -0500 (CDT)

I'm a developer working on Ghostscript, and we use libtiff for our TIFF output "devices".

As a matter policy (primarily for easy porting), it's our policy that, wherever possible, libraries we include should be integrated in such a way that they work through Ghostcript's I/O and memory management functions.

I made changes to how we interface with libtiff a while back so the file I/O functions work that way, but looking at the memory management functions, there is no way this can currently be done, due to memory management functions always being called directly (rather than via function pointers, like the file I/O calls), and also there is no "context" passed into the memory functions.

If I were to make changes that would augment the libtiff API to allow an opaque pointer to "user data" to be passed into the memory functions, and changed the memory functions to be called through function pointers like the file I/O ones, would that be something of interest, and likely to be adopted?

I am not so sure about the extra "opaque pointer" bit, but having the ability to specify the memory allocation functions to use (as zlib and libpng do) would be useful.

It's not uncommon for applications that implement their own memory management to require a "context" of some kind to be passed to the memory management calls, especially when thread safety is required - hence the "opaque pointer".

A key issue is that the existing libtiff ABI can't be impacted by any such change.

From what I understand, the "struct tiff" data type is not part of the ABI - being intended as opaque to the calling code. So I can add function pointers, and possibly a new "client context" pointer to that without affecting the ABI. To use the new capabilities, there would be new API calls, with the existing APIs being unaffected.

Chris