TIFF and LibTiff Mail List Archive


2001.06.12 09:42 "Possible bug with SBYTE type", by Neil Talsania
2001.07.27 20:24 "Re: Possible bug with SBYTE type", by Andreas R. Kleinert

2001.06.12 09:42 "Possible bug with SBYTE type", by Neil Talsania


I am currently using version 3.5.5 of the library compiled on solaris 2.6 using the sun Forte compiler. I have run into what I think is a bug, but before entering it into the system, I thought that I would describe what I am seeing and see if maybe I am misinterpreting things.

Here is what I am trying to do. I have an image that is of type CHAR, thus the range of values are from -128 to +127. I am trying to set the SMIN tag to -128, however when I get the value back it is +128.

So, then I started looking at the code. And I verified with a debugger that the value that I am trying to write is -128. The problem seems to be when I read it back in. Because the type for the SMIN tag is of type any, and my data is CHAR, it is getting written out as a SBYTE type. When this gets read back in, the data is promoted to a USHORT in the call to FetchByteArray, then the value is casted back to a SHORT, however by this time the sign has been lost, and now my -128 (which I believe would be 10000000 in twos complement binary representation for a single byte) has become +128 (which for a short would be represented by 0000000010000000).

I have not come up with a solution yet, but it seems that in the FetchByteArray, the shift that is done needs to be done with a signed value if the data is type SBYTE. However, I have only just begun looking at the library code, and any change to the FetchByteArray function would impact a lot more than just the smin and smax tags, so I was hesitant to muck around too much. I dont want to do anything that will bite me later on.

Any thoughts on this? Am I misinterpreting what should be happening? Any thoughts on how to fix this?


Neil Talsania