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
sys/base64: Fix, unit test cleanup, and benchmark #14400
Conversation
|
Somehow the build was previously not queued, toggling |
|
Looks like the unit test will now fail
|
|
No need to run tests on hardware. The compilation tests include a run of the unit tests on the |
|
@mjurczak: I cherry-picked your suggested fix and included it in the PR. This way, the credit for and authorship of the commits stays with you. |
|
With @mjurczak fix included, the unit tests are now passing. I updated the PR title and the description accordingly. |
|
Fixed some style issues, while we're at it. (I will let Murdock run again when I have squashed.) |
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.
Should the benchmark have an automatic test?
It might be good to split the benchmark from this PR, that way this PR can limit itself to cleanups and the bugfix and can get in right away. But if you add the 01_test.pyscript right away we can get everything in at once, I don't mind.
I'm not sure what an automatic test should do. A single benchmark run will provide a raw number, that lacks context. (Or two raw numbers, one for encode and one for decode.) IMO, at least a second benchmark result from the same hardware is needed to have any meaningful information. What we could do (if we want to run automatic tests), is to feed a database with the raw results to see how performance changes over time. But maybe such considerations should be done independently form this PR and applied later on to all benchmarks. |
I was just thinking on the most basic check, what we do for other benches |
Ah, OK! I added the test. |
|
Please squash @maribu and re-trigger ci. |
Fixed required result buffer size underestimation in base64_estimate_decode_size() function.
This is a non-breaking change, as `unsigned char *` can implicitly be converted to `void *`.
- Added unit test for `base64_estimate_{de,en}code_size()`
- Mark constant stuff as `const`
- Use `memcmp()` for comparing memory
- Do not use variable size arrays
- Various code style issue
|
I fixed a typo in the test input detected by the static tests (and the corresponding base64) and added the missing empty line flake8 complained about. I squashed right away. |
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.
ACK, bug pointed out by @mjurczak is addressed with a unit-test exposing it. Cleanups go according yo our coding style. Lets see what murdock has to say.
|
Murdock likes it too. |
|
@mjurczak: Thank you very much for reporting and fixing the issue! Thanks everyone for the reviews. |
|
@maribu I'm stunned with the fast reaction. Great job everyone! |
Contribution description
voidpointers for buffers (non-breaking change, asunsigned char *is implicitly casted tovoid *)base64_estimate_{de,en}code_size()Testing procedure
The unit tests should no detect an issue in
base64_estimate_{de,en}code_size()Issues/PRs references
None