[fitsbits] Possible bug in CFITSIO

David C. Partridge david.partridge at perdrix.co.uk
Thu Feb 27 06:54:52 EST 2020


===== QUOTE =====
Although FITS does not directly support unsigned integers as one of its
fundamental data types, FITS can still be used to efficiently store unsigned
integer data values in images and binary tables. The convention used in FITS
files is to store the unsigned integers as signed integers with an
associated offset (specified by the BZERO or TZEROn keyword). For example,
to store unsigned 16-bit integer values in a FITS image the image would be
defined as a signed 16-bit integer (with BITPIX keyword = SHORT_IMG = 16)
with the keywords BSCALE = 1.0 and BZERO = 32768. Thus the unsigned values
of 0, 32768, and 65535, for example, are physically stored in the FITS image
as -32768, 0, and 32767, respectively; CFITSIO automatically adds the BZERO
offset to these values when they are read.
===== END QUOTE =====

With that in mind I believe that the code in fffi2i2 (for example) at line
1054 is incorrect as it always adds the zero value before checking for an
overflow error.

I think that it should check the value is in range and ONLY then add the
zero value.

IOW:

            for (ii = 0; ii < ntodo; ii++)
            {
                dvalue = input[ii] * scale;   // don't do + zero;

                if (dvalue < DSHRT_MIN)
                {
                    *status = OVERFLOW_ERR;
                    dvalue = DSHRT_MIN;
                }
                else if (dvalue > DSHRT_MAX)
                {
                    *status = OVERFLOW_ERR;
                    dvalue = DSHRT_MAX;
                };
                dvalue += zero;	// NOW Add the zero offset to the validated
value
                output[ii] = (short) dvalue;
            }

Similar issue with handling of 32 bit values.

David




More information about the fitsbits mailing list