64-bit integers in FITS

[Tom McGlynn]

When I wrote a Java FITS reader last year I was considering whether I should
support 64 bit integers and I asked whether there was any need for it.  The response
was underwhelming, but I went ahead and did it anyway.
    (See http://members.home.net/mcglynn/java/nom/tam/fits).

A few points:

   It's very clear how the standard should support this data type, e.g., BITPIX=64
for image data, and TFORM='K' for binary tables.  (16 byte integers will be
a little harder since 'L' is already taken)  This makes adopting it a lot easier.

   I have thought of a few things that people might want to store in 8 byte integers
today or soon.  Presumably this number will increase with time.
For some double precision numbers are not an acceptable alternative.
Note that while we do have ways to indicate that real data is being
encoded as integers  (BZERO/BSCALE, ...) we do not have the inverse: that
value encoded in a double is really an integer.  That's an important thing
to know about an item.

Some things that might need 8 byte integers:
  - As mentioned previously clock times frequently require more than 32 bits.
  - File sizes
  - Verification/encryption keys, e.g., an 8 byte checksum.   Possible rouding errors
     mean that these cannot be stored as doubles.
  - Catalog IDs (e.g., the Monet catalog already has 270 million entries).  Its very useful
     to integer ID's for catalogs but some of the next generations of catalogs will have more than
     4 billion entries.
  - System data (e.g., the one suggestion I had last year was that databases often use
    8 byte quantities).

With regard to Tim Pearson's question of whether we should implement intermediate sizes, the
historical precedent seems to be no:  FITS does not support 24 bit ints.  I think there
are some other problems:  What granularity to support?  What's the format code
in binary tables?    More importantly FITS seems to have evolved such that its
internal formats are compatible with those found on typical hardware.  It would
be a lot more painful to support these intermediate types (e.g., to hande the sign
extension, packing and overflow issues).

There is the question of how to support i*8's on machines which don't have that.
It should be very straightfoward to convert from i*8 to r*8 (not too much worse
than the signed to unsigned conversions) but that won't always be good enough.
This is the one issue that I'd like to understand better before going ahead and
recommending adopting i*8.  What fraction of the community cannot read i*8's?
E.g., do gcc and g77 support it?

            Tom McGlynn