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):
|
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. |
| 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.
Can we please add a static assert that MAX_BLOCK_WEIGHT >= 8000?
There was a problem hiding this comment.
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.
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.
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.