Fix out-of-bounds vector accesses in Pruner::enforce. #398
Conversation
Codecov Report
@@ Coverage Diff @@
## master #398 +/- ##
=======================================
Coverage 69.25% 69.25%
=======================================
Files 67 67
Lines 4993 4993
=======================================
Hits 3458 3458
Misses 1535 1535
Continue to review full report at Codecov.
|
|
James, thanks for the report. On my debian, I cannot trigger the error by enabling D_GLIBCXX_ASSERTIONS in configuration. The tests seem to pass. Testsuite summary for fplll 5.3.0 TOTAL: 13PASS: 13SKIP: 0XFAIL: 0FAIL: 0XPASS: 0ERROR: 0Does the checking error comes from Line 22 of test_pruner.cpp? Shi |
|
Over at fplll/fpylll#161 it seems to remove some non deterministic behaviour, so I'm inclined to merge this soon. Shi, do you sign off on this? |
|
I could not repeat this error on my debian. But see fplll/fpylll#161 that removes error. Happy to merge. |
|
Ta! |
I have been testing builds for fplll 5.3.0 and fpylll 0.5.0dev for Fedora. The default Fedora build flags include -D_GLIBCXX_ASSERTIONS. This led to test failures in fpylll due to out of bounds vector accesses in the fplll code. This commit fixes the two such out of bounds accesses found by the fpylll tests. (I highly recommend that you build with -D_GLIBCXX_ASSERTIONS before running your tests, by the way.)
In the first hunk, note that min_pruning_coefficients always has length d, not n. The fpylll test suite, at least, invokes this code in such a way that i / c can be equal to d and therefore one past the end of the min_pruning_coefficients vector.
In the second hunk, j can be as large as as dn (b.size()), and therefore on the first iteration of the loop, when i is j - 1, then b[i + 1] == b[j] is one past the end of b.