
Thread
2008.05.31 15:45 "Re: [Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10", by Even Rouault
And I suspect that the "_TIFFmemcpy(n,&o->tdir_offset,4)" is also bogus as tdir_offset is 64 bit large too.
That should be fixed too by the same method:
nTemp = (uint32)o->tdir_offset;
_Tiffmemcpy(n, &nTemp, 4);
Those problems are probably not seen on little endian machines as the first 4 bytes contain the lowest 32 bit word, which is the one we want to put into the n pointer... I'm also wondering why there's not a test to see if it must be swabbed afterwards, as it's done for the tag, type and count fields.
Le Saturday 31 May 2008 17:30:11 Even Rouault, vous avez écrit :
Dan,
Your fix is not the right one. But I recognize that my previous suggestion could lead into error.
In fact, tdir_count field is a uint64 in libtiff 4.0.
So the correct fix is:
uint32 nTemp = (uint32)o->tdir_count;
_Tiffmemcpy(n, &nTemp, 4);
> ---------------------------------------------------------------------------
>--------
[Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10
> De :
Dan Greve <grevedan@hotmail.com>
> À :
Bob Friesenhahn <bfriesen@simple.dallas.tx.us>, Even Rouault <even.rouault@mines-paris.org>
> CC :
gdal-dev@lists.osgeo.org, tiff@lists.osgeo.org, Andy Cave <andy.cave@hamillroad.com>, mailing list <tiff@lists.maptools.org>
> Date :
Aujourd'hui 16:49:15
>
Sure enough, the pointer n is not null, and throws a sigsegv fault. Aftern changing from
>
> *(uint32*)n=(uint32)o->tdir_count; TO
>
_TIFFmemcpy(n, &o->tdir_count, 4)
>
The execution passes this point, but where as *(uint32*)n should be 1, it is 0. This causes errors later in the GDALOpen call on the tiff dataset, which fails with error "TiffFetchNormalTag:incorrect count for "SamplesPerPixel". debugging continues....
>
-- Dan Greve
-- Software Engineering
-- Northrop Grumman Corp.
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev