-
Notifications
You must be signed in to change notification settings - Fork 214
do not expose mp_balance_mul, add MP_ENABLED feature detection #213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Changes from all commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
cb73a57
do not expose mp_balance_mul, reorganization in mp_mul
minad f4f50be
introduce MP_ENABLED
minad 620c76f
apply MP_ENABLED at other places
minad e7fdc96
apply to bn_mp_invmod
minad 9421a48
restrict the MP_ENABLED macro to only work with the BN_*_C defines
minad 8ae19ce
formatting again
minad 2752429
apply to bn_mp_sqr
minad 7024133
apply to mp_div_d
minad 0354365
apply to exptmod
minad File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can but should we?
IMO as soon as the library symbols are properly set-up you won't be able to build these tests then against the shared library
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then we need a special test build with exposed s_* symbols. I think it is better if internal functions are tested separately. For example in the mul case we could also test the different code paths by passing the right values. But this is too fragile and I would also like to test edge cases, which would otherwise not be hit.
This would also solve the issue with exposed CUTOFF variables. We should just make those constant and test karatsuba and toom cook separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC they can't be made constant as they vary from platform to platform. Sure they're mostly constant now as nobody's really tweaking them but I guess that's caused by the fact that there's no proper way yet to determine them per platform. (besides running
etc/tune)I'm no big fan of explicit testing of internal functionality.
I prefer that way to make sure the entire chain works and then determine that everything is called through code coverage.
why is this too fragile?
why would you want to test cases which can't be hit?
that all sounds a bit over the top to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not saying to test arbitrary internal things. However internal functions with a well defined API should be tested, e.g., mp_balance_mul. @czurnieden also added the balance mul test to the test suite, but he did not call it directly which he should have. If only the external api should be tested, there should not even be a function test_balance_mul.
If you want that - then the test suite must be split such that internal function tests and api function tests can be compiled separately. No big deal.
#if TEST_INTERNAL .... #endif.Ensure that stuff is hit via code coverage is good practice, but not enough and it depends on external tooling. Do we have coverage set up?
Besides, if we would just start renaming internal functions to
s_*, we wouldn't have to tweak the visibility settings in the first step. Thes_*functions would just be internal and not belong to the public ABI by our own convention. In the next step we could make the symbols hidden.The test of the internal function mp_balance_mul should not depend on the criterion at which this function is selected in mp_mul.
Robustness of the functions. I would not extend functions to accept values which cannot be handled fundamentally, but for example if karatsuba also works for small numbers and these should be tested too.
No it is not. If you want to see something which is over the top look at the sqlite test suite. What I am proposing here is good practice and modest. It is also too much work hopefully. Furthermore there are people willing to improve stuff, like me getting this test suite refactoring started.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not if this test is specifically crafted to test
mp_balance_mulwithinmp_mul?you can do
make coverage:)fine by me, keep the discussion points of #172 in mind
what sense does a specific test even make if its counterpart isn't available? as it is now the test's can't even be built w/o
mp_balance_multhen set the cutoff in the testcase appropriately?