Note that the checksum field must be four-byte integer aligned, whether the checksum is being stored as an integer or as an encoded string (equivalent to four sequential integers). In either case, this requirement only applies byte-by-byte due to the commutativity and associativity of 1's complement arithmetic--any file can be reshuffled without affecting the checksum as long as the location of each byte modulo 4 is preserved. This may be considered a weakness of the 1's complement checksum, but only if such a wholesale reshuffling is a likely error that must be guarded against. It is also a strength of the algorithm since the checksum field may be positioned at an arbitrary odd byte offset just by permuting the bytes while preserving their relative offsets. This would not be possible for algorithms such as the 2's complement checksum and the CRC (§4) whose values depend on the order in which the bytes are summed.
This proposal requires that the initial quote for the CHECKSUM
keyword must be located in column 11 to agree with
the FITS fixed format character string conventions. Column 12
contains the final byte of the same four byte word (that contains
column 11). To ensure proper integer alignment the final byte
(character) of the encoded string must either be permuted to the
beginning of the string, or column 12 (the first character of the
string) must be left blank. (Recall that leading blanks are significant
in FITS keyword values.) This proposal mandates that the bytes
be permuted. (ASCII blanks are represented by ``
''.)
1 2 1234 5678 9012 3456 7890 1234 5678CHEC KSUM
= 'h
cHjj c9gh cEgh c9g'
correctCHEC KSUM
= '
cHjj c9gh cEgh c9gh'
The two arrangements (other more complicated permutations are possible) are shown with the alignment on four byte word boundaries indicated by spacing. The 16 character values of each encoded unsigned integer have identical effects on the file checksum, ignoring punctuation, but only the first is permitted by this proposal.