2013.08.02 08:04 "Re: [Tiff] memory management function calls", by Chris Liddell

2013.09.04 14:24 "Re: [Tiff] memory management function calls", by Bob Friesenhahn

I don't have a problem with it being rejected for those reasons, but I was concerned (due to the lack of responses) that referring to a browsable git repo for a first review wasn't liked. I wouldn't like it to be rejected because of that.

Maybe people are not used to such conveniences. Bear skins and stone knives are the norm here. :-)

The main impact of the changes is that it is done by creating a new TIFFClientOpen() type interface with additional parameters. Other libraries change the allocator using global variables but the proposed change allows the allocator to be changed on an individual open basis. This could be used to support multiple threads with zero heap contention in the allocator if the allocator is designed to support it.

  457 extern TIFF* TIFFClientOpenCTX(const char*, const char*,
  458             thandle_t,
  459             TIFFReadWriteProc, TIFFReadWriteProc,
  460             TIFFSeekProc, TIFFCloseProc,
  461             TIFFSizeProc,
  462             TIFFMapFileProc, TIFFUnmapFileProc,
  463             void *,
  464             TIFFmallocCTXProc, TIFFreallocCTXProc, TIFFfreeCTXProc);

As a result of the approach, the biggest change is to pass the TIFF handle where it was never required before and so many lines of code are changed. If malloc/free need to be introduced in new/modified code, then the TIFF handle needs to be passed to that code.

There is only benefit to the user if they already used TIFFClientOpen() and can easily update to use TIFFClientOpenCTX() or are willing to significantly update their code to use TIFFClientOpen() type operation.

You already know the above but I post it as benefit for those who did not look at your repository.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/