2015.07.14 13:39 "Re: [Tiff] TIFFClientOpen when writing... Bug?", by Scott Weber

I was incorrect regarding the statement about "TIFFgetMode'. However the issue is still valid regarding reading and looking for the magic header when it is intending to write.

Scott Weber

On Tue, Jul 14, 2015 at 8:19 AM, Scott Weber <scotty2540@gmail.com> wrote:

I am implementing the TIFFClientOpen(...) methods for reading a writing in memory.

Reading works fine. The problem is that "writing" is trying to "read".

I set up the call with all the callback functions (they are inside an instantiated class):

    hTif = TIFFClientOpen("OUT","w",
         (thandle_t)this,
        tiff_Read, tiff_Write, tiff_Seek,
        tiff_Close, tiff_Size, NULL,NULL);

And I see that is attempts to read 8 bytes from the beginning of the buffer.

As I step through and debug the lib, I am seeing bizarre things.

Specifically, inside the TIFFClientOpen function, it does the following: Calls "TIFFgetMode(..)" and assigned O_RDWR, O_RDONLY, etc... flags. I see that it tries to decide if it must add the O_TRUNC flag, but the structure of the code is such that it can never happen.

( inside case 'a', if mode[0] == 'w'... which is impossible, because
mode[0] was 'a' )

Later one, there is a peice of code:

     if   (....    !ReadOK( tif...   )

Which tries to do an initial read of the buffer, and verify that the magic header is correct.

So then...

If we are "writing" in what should essentially be a new buffer, why is it trying to read that buffer first to see if it is a valid TIFF?

I could make the alterations I think are correct, but I am reluctant to start messing with the lib because of my unfamiliarity with it's inner workings.

(for example, if I remove that test during "write", does some other portion of the code put the magic bytes there anyway?)

Any advice is appreciated.