Comments on NOST 100-1.2

[John E. Davis]

On 12 Jul 1998 10:43:53 -0400, Thierry Forveille <Thierry.Forveille at obs.ujf-grenoble.fr>
wrote:
>I must say I have never seen any convincing argument for supporting
>unsigned values. The present "hack" as you call it offers all the
>functionalities for no cost, while adding unsigned as an additional
>supported format would cost significant extra code to everybody for no
>additional value. To me Occam's razor says it should stay out...

Please correct me if I am wrong, but my main objection to this
convention is that it is inherently non-portable because the BZERO
value that must be used is outside the range of the integer data type.
For example, to represent an unsigned 32bit integer, BZERO must be set
to 2147483648 in the fits file, which is outside the range of a 32 bit
signed integer.  Why is this a problem?  It is a problem because
parsing it as a 32 bit integer may result in its truncation.
Specifically, CFITSIO uses the strtol function call to parse these
values and this function will truncate 2147483648 to 2147483647.

To see this, consider:

#include <stdio.h>
#include <stdlib.h>

int main ()
{
   long i;
   char *s;

   s = "2147483648";
   i = strtol (s, NULL, 10);
   fprintf (stdout, "%s = %ld\n", s, i);

   s = "2147483647";
   i = strtol (s, NULL, 10);
   fprintf (stdout, "%s = %ld\n", s, i);
   
   return 0;
}

     
Compiled with gcc on my Linux system, this produces:

   2147483648 = 2147483647
   2147483647 = 2147483647

The man page for strtol indicates:

RETURN VALUE
       The  strtol()  function  returns the result of the conver¡
       sion, unless the value would underflow or overflow.  If an
       underflow  occurs, strtol() returns LONG_MIN.  If an over¡
       flow occurs, strtol() returns LONG_MAX.   In  both  cases,
       errno is set to ERANGE.

It is possible avoid strtol with a different function, but one would
still need to perform integer multiplications which would result in
overflow.  About the only portable alternative would be to use double
precision arithmetic but even that may not be sufficient if you want
to use this convention to represent 64 bit unsigned values.

So, without real support for unsigned types, I maintain that this
convention is flawed.

Thanks,
--John