Intended usage of the CFDP checksum

[JackNWhite]

I'm experiencing some confusion over the intended operation of the CFDP checksum update:

namespace CFDP::Checksum
{
      //! Update the checksum value by accumulating the words in the data
      void update(
          const U8 *const data,   //!< The data
          const U32       offset, //!< The offset of the start of the data, relative to the start of the file
          const U32       length  //!< The length of the data in bytes
      );
}

I'm not sure this is working correctly. My understanding, from the text in the CFDP spec, is this:

You assume the start of a file is aligned and then, starting with 0, update a 32-bit checksum by treating it as 4 bytes. You move along the file, moving a 4-byte window by 4 bytes each time. You do a byte-wise sum of the existing checksum and the 4 bytes of file data inside the window. If you are starting at an unaligned offset, that is, not a multiple of 4, then you prefix the 4-N bytes of unaligned data with the appropriate number of zeros. If you end at an unaligned offset, then to suffix with zeros. You ignore the overflows on the additions.

For buffer 0xDE 0xAD 0xBE 0xEF 0xCA 0xFE 0xD0 0x0D
Window1    0xDE 0xAD 0xBE 0xEF
Chksum1    0xDEADBEEF

Window2    0xCA 0xFE 0xD0 0x0D
Chksum2    0xDEADBEEF+
           0xCAFED00D
           ----------
           0xA8AB8EFC

This doesn't work. I wrote this quick test for the Checksum class.

TEST(Checksum, Jacket)
{
  // The whole file for which I want a checksum
  U8 const my_data[]          = {0xfb, 0x02, 0xc8};

  // The whole file, padding to fill out a whole word; should have the same checksum as the whole file
  U8 const my_padded_data_1[] = {0xfb, 0x02, 0xc8, 0x00}; // Window 0xfb, 0x02, 0xc8

  // Should have the same checksum as the file *if* you start at offset 1
  U8 const my_padded_data_2[] = {0x00, 0x02, 0xc8, 0x00}; // Window       0x02, 0xc8

  // Should have the same checksum as the file *if* you start at offset 2
  U8 const my_padded_data_3[] = {0x00, 0x00, 0xc8, 0x00}; // Window             0xc8

  // I call these ones the fakes - manual padding!
  Checksum checksum1(0u);
  Checksum checksum2(0u);
  Checksum checksum3(0u);

  checksum1.update(my_padded_data_1, 0, 4);
  checksum2.update(my_padded_data_2, 0, 4);
  checksum3.update(my_padded_data_3, 0, 4);

  Checksum checksum(0u);
  checksum.update(my_data, 0, 3);
  ASSERT_EQ(checksum.getValue(), 0xfb02c800) << " real 1/3";
  ASSERT_EQ(checksum.getValue(), checksum1.getValue()) << " fake 1/3";

  checksum = Checksum(0u);
  checksum.update(my_data, 1, 3);
  ASSERT_EQ(checksum.getValue(), 0x02c800) << " real 2/3"; // Fails - is 0xfb02c8
  ASSERT_EQ(checksum.getValue(), checksum2.getValue()) << " fake 2/3";

  checksum = Checksum(0u);
  checksum.update(my_data, 2, 3);
  ASSERT_EQ(checksum.getValue(), 0xc800) << " real 3/3";
  ASSERT_EQ(checksum.getValue(), checksum3.getValue()) << " fake 3/3";
}

The checksum calculated on my_data from offset 1 should be 0x2c800 - and this is what you get if you manually pad my_data - but it is actually 0xfb02c8.

This seems unintended. In fact, if you change the update from checksum.update(my_data, 1, 3); to checksum.update(my_data, 1, 2);, the answer doesn't change either.

[JackNWhite]

Ok, I see my mistake here - the length is the length of the piecemeal data over which to update, and the address is the address of the start of the piecemeal data, not the start of the buffer/file.

I think this function works in an unexpected and surprising way and that the Doxycomments are confusing. I will submit a modification.