[gnuastro-commits] master b08f331: Identifiers for integer constants in BZERO comparisons

[Mohammad Akhlaghi]

branch: master
commit b08f33164617a20a61e287c10bff6255ae40fe18
Author: Mohammad Akhlaghi <address@hidden>
Commit: Mohammad Akhlaghi <address@hidden>

    Identifiers for integer constants in BZERO comparisons
    
    For each integer width, the FITS standard only defines one type: unsigned
    8-bit, signed 16-bit and so on. So to allow other types (for example signed
    8-bit or unsigned 16-bit), it defines constant values for BZERO. The
    constants for 8-bit and 16-bit integers have no particular problem, but for
    the 32-bit and 64-bit integers, if there is no identifiers, the compilers
    may produce warnings (on 32-bit and 64-bit systems).
    
    Until now, only the 64-bit value was given an identifier of `.0f' to read
    it as float. But floats (even double precision), don't have the necessary
    resolution for such large integers (`double' can only accurately keep an
    integer until 15 significant decimal digits). For the 32-bit value, I got a
    compiler warning on a 32-bit `armv81' GCC ("Warning, this decimal constatn
    is unsigned only in ISO C90").
    
    To fix the problem, the `LU' and `LLU' identifiers were added for the
    32-bit and 64-bit constants of `fits_type_correct'. However, this doesn't
    fix another problem with comparing a floating point to the 64-bit integer
    constant. In a check, I noticed that after defining `a' and `b' as: `double
    a=9223372036854775808LLU, b=9223372036854775807LLU;' (note that `a=b+1'),
    the condition `a==b' succeeds (because of limited floating point
    precision). So I just sent a mail to William Pence (author of CFITSIO)
    about the issue to get his comments.
---
 lib/fits.c | 44 +++++++++++++++++++++-----------------------
 1 file changed, 21 insertions(+), 23 deletions(-)

diff --git a/lib/fits.c b/lib/fits.c
index 4cddcc6..8934585 100644
--- a/lib/fits.c
+++ b/lib/fits.c
@@ -470,42 +470,40 @@ gal_fits_datatype_to_type(int datatype, int 
is_table_column)
    type that must be used to store the actual values of the pixels may be
    different from the type from BITPIX. This function does the necessary
    corrections.*/
-void
+static void
 fits_type_correct(int *type, double bscale, double bzero)
 {
   int tofloat=1;
 
-  /* Work based on type, for the default conversions defined by CFITSIO,
-     make the proper correction, otherwise set the type to float. */
+  /* Work based on type. For the default conversions defined by the FITS
+     standard to change the signs of integers, make the proper correction,
+     otherwise set the type to float. */
   if(bscale==1.0f)
     switch(*type)
       {
       case GAL_TYPE_UINT8:
-        if(bzero == -128.0f)  { *type = GAL_TYPE_INT8;   tofloat=0; }
+        if(bzero == -128.0f)      { *type = GAL_TYPE_INT8;   tofloat=0; }
         break;
 
-    case GAL_TYPE_INT16:
-      /* Defined by the FITS standard: */
-      if(bzero == 32768)      { *type = GAL_TYPE_UINT16; tofloat=0; }
-      break;
+      case GAL_TYPE_INT16:
+        if(bzero == 32768)        { *type = GAL_TYPE_UINT16; tofloat=0; }
+        break;
 
-    case GAL_TYPE_INT32:
-      /* Defined by the FITS standard: */
-      if(bzero == 2147483648) { *type = GAL_TYPE_UINT32; tofloat=0; }
-      break;
+      case GAL_TYPE_INT32:
+        if(bzero == 2147483648LU) { *type = GAL_TYPE_UINT32; tofloat=0; }
+        break;
 
-    case GAL_TYPE_INT64:
-      /* Defined by the FITS standard: */
-      if(bzero == 9223372036854775808.0f)
-        {*type = GAL_TYPE_UINT64; tofloat=0;}
-      break;
+      case GAL_TYPE_INT64:
+        if(bzero == 9223372036854775808LLU)
+          {*type = GAL_TYPE_UINT64; tofloat=0;}
+        break;
 
-    /* For the other types (when `BSCALE=1.0f'), currently no correction is
-       necessary, maybe later we can check if the scales are integers and
-       set the integer output type to the smallest type that can allow the
-       scaled values. */
-    default: tofloat=0;
-    }
+        /* For the other types (when `BSCALE=1.0f'), currently no correction is
+           necessary, maybe later we can check if the scales are integers and
+           set the integer output type to the smallest type that can allow the
+           scaled values. */
+      default: tofloat=0;
+      }
 
   /* If the type must be a float, then do the conversion. */
   if(tofloat) *type=GAL_TYPE_FLOAT32;