Comments on NOST 100-1.2

[William Pence]

Regarding Arnold's questions, I have checked the CFITSIO code and run some
test programs to verify that CFITSIO does read and write unsigned integers
correctly.  Internally, CFITSIO reads and writes the TZEROn or BZERO keyword
as a double, not as an integer, so CFITSIO is unaffected by the supported
range of the integer datatype in this case.  Also, as Arnold suggested,
CFITSIO does test for the special values of BZERO or TZEROn that represent
unsigned integers, and then just flips the sign bit, instead of adding
BZERO, for better reading or writing efficiency. In summary, then, there is
no problem using CFITSIO to read or write unsigned integers in FITS file.

John Davis' example, does however show that CFITSIO currently does not check
for overflows when reading keyword values (for both integers or reals). 
Thus, for example, when reading the BZERO = 2147483648 keyword as a signed
4-byte integer, the value may be silently truncated to the maximum value of
a signed integer (this behaviour is compiler dependent).  Similarly, trying
to read a real keyword with a value = 1.5E+32 as an integer, could also
return a value = 2147483647 without any errors.  This behavior is not what
most users would want or expect, so the next release of CFITSIO will contain
more range checking code that will return an error status whenever an
overflow occurs while reading keywords.

-Bill Pence

Arnold Rots wrote:
> 
> Unless I am unusually dense (which always remains a possibility o
> Monday mornings), the attached two paragraphs from Bill Pence's
> message seem to be at odds with each other and do not really address
> the issue John Davis was raising.
> 
> If John is right in his interpretation of what cfitsio does, things
> are far from transparent to the programmer and we have a serious
> problem - a problem that cannot be dismissed with "it's your
> compiler's fault".  I tried his little test on a Sparc, using gcc
> and, not surprisingly, it failed in the same way.  Hence, using gcc on
> a 32-bit machine (hardly an uncommon combination) will get one into
> trouble.
> 
> It means that anybody using the unsigned integer facilities in cfitsio
> is at risk: all purportedly unsigned longs will come out one too small
> on a common platform-compiler combination.  The fact that we have not
> heard any complaints probably has to do with the rather recent
> introduction of this feature which undoubtedly has not made it into a
> lot of application code.
> 
> It would seem prudent, though less elegant, to test whether
> BZERO/TZERO represents the signed/unsigned hack (yes, it _is_ a hack)
> and then simply flip the most significant bit.
> 
> Could Bill comment onm this?  Do we have a serious problem or do we
> misunderstand the way things are handled in cfitsio?
> 
> Thanks,

____________________________________________________________________
Dr. William Pence                          pence at tetra.gsfc.nasa.gov
NASA/GSFC Code 662         HEASARC         +1-301-286-4599 (voice)     
Greenbelt MD 20771                         +1-301-286-1684 (fax)