[PATCH v4 2/5] CRC64 testsuite

[Ulf Samuelsson]

On 2023-02-28 14:06, Nick Clifton wrote:
> Hi Ulf,
>
>> I am considering ”cheating” by always storing the CRC as big endian.
>> That would simplify the test.
>> It would also make the CRC readable in the text output.
>> Drawback is of course that small endian targets would have to swap 
>> the CRC before use.
>
> I expect that users of little endian targets would complain about that 
> ...
>
Yes,

 From a useability point of view it is not ideal.

Since I am not familiar with Perl,
I would like to avoid digging down in the test harness.

I can test the endianess of the host, and "link_info.big_endian"
tells the endianess of the target. Based on that I can make decisions
in the linker.

I can see some alternative.

* Always storing the small-endian version - same complaint from fewer 
people.
* Store both big-endian and small-endian - wastes 4-8 bytes of space
* Adding a switch to force to use "natural" endianess.
* Adding something to the command.
   Stored as small endian, unless you have an extension
   DIGEST "<poly>.BE" ?

   I.E:
   DIGEST "CRC64-ISO.BE" ?
   That removes the test problem, but if we want to test every algorithm
   this way, the tests are multiplying.

============================================

The CRC table is another issue

Right now, only the endianess of the table is that of the host.
This needs to change, but that is not difficult, except how to control it.

If we explicitly tell the endianess of the table, we get rid of the test 
problem.

DIGEST TABLE "<label>"        - stored as small endian declaring <label>

DIGEST TABLE "<label>.LE"    - stored as small endian declaring <label>

DIGEST TABLE "<label>.BE"   - stored as big endian declaring <label>

The table is a nice addition, but not necessary.
The user can avoid the "DIGEST TABLE" command and put their
own table in their code.

Best Regards
Ulf

> Cheers
>   Nick
>
>