-
Notifications
You must be signed in to change notification settings - Fork 37.7k
refactor: Use C++17 std::clamp #23095
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
Conversation
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
7583dee
to
334df35
Compare
334df35
to
d335443
Compare
d335443
to
82c4e71
Compare
Concept ACK |
Concept ACK
|
Concept ACK I wonder whether this is a good candidate or not: bitcoin/src/rpc/blockchain.cpp Line 1859 in 58c25bd
|
Some tests fail with this line being changed. |
In case you think it is a good candidate for changing to |
Branch: 7583dee |
Ouch-if tests fail that means the behavior is not the same. I think we should be careful here. For the C++11 transition we even had an explicit rule not to do all-over-the-place code modernization like this, it's very easy to accidentally introduce a bug. I'm all for using |
This is not a trivial replacement. With std::min/max the argument order doesn't matter (min(a,b)==min(b,a)). However, with |
I think the test has failed because
Not only that, there can be cases where there is no order that is always correct :) |
82c4e71
to
bf4838e
Compare
Updated 82c4e71 -> bf4838e (pr23095.04 -> pr23095.05):
|
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.
Code review ACK bf4838e
bf4838e
to
665353f
Compare
Updated bf4838e -> 665353f (pr23095.05 -> pr23095.06, diff):
|
This change improves code readability.
Updated 665353f -> 512dcf7 (pr23095.06 -> pr23095.07) due to the conflict with #23137. |
@@ -64,7 +64,7 @@ BlockAssembler::BlockAssembler(CChainState& chainstate, const CTxMemPool& mempoo | |||
{ | |||
blockMinFeeRate = options.blockMinFeeRate; | |||
// Limit weight to between 4K and MAX_BLOCK_WEIGHT-4K for sanity: | |||
nBlockMaxWeight = std::max<size_t>(4000, std::min<size_t>(MAX_BLOCK_WEIGHT - 4000, options.nBlockMaxWeight)); | |||
nBlockMaxWeight = std::clamp<size_t>(options.nBlockMaxWeight, 4000, MAX_BLOCK_WEIGHT - 4000); |
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.
Can we please add a static assert that MAX_BLOCK_WEIGHT >= 8000
?
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.
Wouldn't it be better to have a clamp function that does this by default, internally and at compile time? The condition must hold for all call sites.
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.
Though in most cases it's not possible to verify it at compile time, this would handle only the 'between two constexpr' case. In other cases there might be non-trivial error handling.
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.
For the cases where it is not possible to verify at compile time, crashing the node seems preferable over UB. Or is this something that sanitizers can spot?
Code review ACK 512dcf7 |
Slightly tend toward NACK. It is non-trivial to review (#23095 (comment)) and easily introduces UB, if the second or third argument are not compile time constants (#23095 (comment)). |
Closing. |
Maybe write a |
This PR improves code readability.
Only safe cases with guarantee of no undefined behavior.