On Wed, 19 Mar 2025 19:00:37 GMT, Anthony Scarpino <ascarp...@openjdk.org> wrote:
>> I was mostly attempting to test 'random paths' through the code, and this >> was a way to pseudo-randomly accomplish that. (i.e. a product of a >> difference, a product of a product.. and so on..) >> >> Since this is looping, we got 50% chance of getting both, without me having >> to write/think-through all the many permutations of what input/outputs to >> each operations can be. >> >> (Extend the loop count to run for several hours during development.. and it >> does wonders to testing corner cases. Have been following this 'template' in >> most my PRs) > > Randomness isn't idea for reproducibility. If a failure occurs, is it > obvious what operations were done? I don't see any stdout or stderr messages > to know what operations happen to bring about a possible failure. I used it this testcase for development (and figured I should also check it in..) so what might be 'obvious' to me, might not be for anyone else? Typically, when a test failed, I grabbed the SEED from the test output, reran the test with that seed fixed and I went to the exception and printed the hex values of the inputs; (then debug from there. Typically, I would write another test, so I could GDB into the intrinsic, with just those input values). It was pretty much always the case always that once I got the inputs, I could reproduce the error i.e. not a type of bug that happens silently then discovered somewhere else. Luckily. All this crypto code is constant-time -no-branches-; so the 'test coverage' here is not 'all-branches-taken' but really 'did you remember to collect all the carries'. like 53-bit limb needs to be propagated back down to 52. Thats what the test here is 'searching' for, some input that could trip up computation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r2004440368
