[fitsbits] 64-bit integers

[Thierry Forveille]

William Pence writes:
 > It is perfectly legal now to create FITS files with integer keywords 
 > larger than the range of a 32 bit integer.  In particular, there is 
 > no limit on the size of the NAXISn keywords, so images with more 
 > than 2**32 pixels in any dimension, or a table with more than this 
 > many rows are allowed.  The only place where the current FITS standard 
 > restricts the size of a FITS file is in the size of the binary table 
 > heap because the 'P' variable length array descriptors only contain 
 > 32-bit addresses.  The proposed 'Q' descriptor, with 64-bit addressing, 
 > would allow a much larger heap to be used.  Otherwise, the proposal to add 
 > support for the 64-bit integer data type in FITS images and tables has 
 > little to do with the size of the FITS file itself.
 > 
Indeed. I did realize that, but my message was in retrospect ambiguous on that
point. Thanks for clarifying.

 > 3.  A couple of months ago, CFITSIO was modified to demonstrate the 
 > feasibility of supporting unsigned integer descriptors.  This turned out to 
 > be trivial to implement.  It provides a practical demonstration that there 
 > is no difficulty in supporting the larger heap size.  Since there was never 
 > any practical use for a negative signed descriptor value, it seems 
 > desirable to reverse the decision made 6-months ago and now define the 
 > descriptors to be unsigned integers, thus doubling the maximum size of 
 > the heap.  This change cannot affect or invalidate any existing FITS 
 > files so it does not violate the 'once FITS always FITS rule'.
 > 
On the other hand, introducing unsigned integers specififically for
heap pointers slightly mars the homogeneity of the standard, since they
are not supported in any other role. Also, 2^63 gets us to 9 million
Terabytes, so even if disk capacity keep doubling at its current
every ~18 months it will take another 30+ years before the difference
between 2^64 and 2^63 could possibly matter.