> Bug: code reads one more word from memory than it should. This is a good idea. The nice thing with CRC its that it's pseudo-random so having the extra trailing randomb bytes helps us catch this but also even uninitialised memory at the end of the string is going to make the tests fail if we read more than requested. We also have 0-length reads in the mix which is a no-op and returns 0x00000000 as a result.
On Thu, 24 Oct 2024 at 23:08, Bruno Haible <br...@clisp.org> wrote: > Sam Russell wrote: > > I think we are massively overengineering this. We shouldn't need to > > future-proof tests for changes that *might* be added in the future, and > > having 32x32 hashes in a table at the start of the test is not a big deal > > (it took less than a second to generate and it'll take the same amount of > > time if we extend to 64 bytes in the future) but it does illustrate that > we > > are perhaps taking a bad approach to testing here. > > As you can imagine, I disagree. > > Tests ought to be designed to > - catch wrong behaviour that you can think of, > - catch wrong behaviour that you haven't think of — after all, our > imagination is limited, > - be maintainable. > > > Let's look at some the scenarios for how the code could potentially be > > broken, and how we could detect this: > > > > === > > Bug: code incorrectly generates checksum in the slice-by-8 code > > === > > > > === > > Bug: code triggers a CPU fault when reading an unaligned word > > === > > Bug: code reads one more word from memory than it should. > (Cf. > https://sourceware.org/git/?p=glibc.git;a=commit;h=2bd779ae3f3a86bce22fcb7665d740b14ac677ca > ) > Detection: Use zerosize-ptr.h, like in test-memchr.c. > > Bruno > > > >
