[fitsbits] Bintable proposals

[Doug Mink]

Clive Page wrote:

> On Fri, 16 Nov 2001, Mark Calabretta wrote:
> 
> > This raises another question: what should a general bintable reader do if
> > it encounters an EOF before reading the number of rows specified by NAXIS2?
> > Hopefully not crash!  So should it adjust its own value of the number of
> > rows to reflect what it found (if it matters)?  If so, could we instead set
> > NAXIS2 to some huge value and rely on the EOF?
> 
> The problem is that a FITS reader gets data in block of 2880 bytes and any
> FITS file with an incomplete final block would surely crash a lot of FITS
> readers.  So I assume the proposal is to have a final block which has the
> standard length, but is incompletely filled with rows.  If you find an
> unexpected EOF, therefore, how do you know how many rows there were?  The
> last row might be anywhere in the final 2880-byte block (assuming the
> row-length is less than 2880 bytes, it need not be of course).  One cannot
> rely on the file beyond the last row being padded with zeros (or some
> other pre-defined bit-pattern), because in general in a binary table (or
> image) any bit-pattern might be legal.   Or have I missed something?

Although I haven't seen such a file recently, I have come across quite a
few "FITS" files with unpadded final blocks; hence all of the FITS readers
I have written over the years have accepted short final blocks, if the number
of rows and columns matched the header.  I figure that my job is to read
the data, whether it exactly fits the standard or not.  I try to always
write files which meet the NOST standards, even if the input is slightly
weird.

If NAXIS2 is not known, for whatever reason, it does seem the safest way
to go with regard to data integrity is to not pad out the final block.
This whole problem cries out for SIMPLE=F, anyway.

-Doug Mink