CRC calculation does not match expected values in functional test

[jphickey]

Describe the bug
Functional test reports the following results:

[ PASS] 22.009 es_misc_test.c:47 - Result = CFE_ES_CalculateCRC(Data, sizeof(Data), 0, CFE_MISSION_ES_DEFAULT_CRC)
[  MIR] 22.010 es_misc_test.c:48 - Confirm mission default CRC of "Random Stuff" is 20824
[ PASS] 22.005 es_misc_test.c:46 - Result = CFE_ES_CalculateCRC(Data, sizeof(Data), inputCrc, CFE_ES_CrcType_CRC_16)
[  MIR] 22.006 es_misc_test.c:47 - Confirm CRC16 of "Random Stuff" with input CRC of 345353 is 4294967180

However, manual inspection - via a 3rd party implementation of CRC-16/ARC (the algorithm used in ES) indicates these values are not correct. The CRC of "Random Stuff" (12-octet) string should be 0x11E3 (decimal 4579) not 0x5158 (decimal 20824).

To Reproduce
Run unit tests and inspect the test results labeled "MIR".

Expected behavior
Values should match a 3rd party implementation.

System observed on:
Debian

Additional context
The reference documentation for "official" CRC implementations usually cite a check value which is the correct computation of a CRC over the string 123456789. For CRC-16/ARC, this check value is 0xBB3D (see here: https://reveng.sourceforge.io/crc-catalogue/16.htm).

The functional test should add a test case for this string using this check value, and furthermore it shouldn't be "MIR" -- there is only one correct/acceptable answer for a CRC-16/ARC on a known input. Currently, CFE ES does not allow for different algorithms/polynomials - there is just one defined - so there is just one correct result.

Reporter Info
Joseph Hickey, Vantage Systems, Inc.

[jphickey]

Worth noting that this API is designed to allow different CRC types, but no such feature was ever implemented nor asked for by any users. Only a single implementation - which is CRC-16/ARC - was ever implemented, and nothing else is used anywhere in CFE/CFS.

Going forward - suggesting we consider a simpler declaration for ease-of-use:

uint32 CFE_ES_ComputeDefaultCRC(const void *DataPtr, size_t DataSize);

This would use the default CRC algorithm, and always start from an initial value of 0, which is the way this is used in most cases. The CS app is the exception that computes a CRC over several cycles, and thus needs to pass in an initial value that is not 0. To support this case as well as to preserve backward compatibility, the existing API will not change.