This is a common concept which is more communicative and explicit if articulated, IMO.
This could be applied elsewhere if there is a better place to reference it in common, but I don't see it.
Pulled from #25315 to ease review there.
Concept ACK
if there is a better place to reference it in common, but I don't see it.
Right, not sure init.cpp is the best place for this constant, but the idea of having it as a named constant makes sense to me, it tells anyone encountering the code about intent and the unit.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
<!--174a7506f384e20aa4161008e828411d-->
Reviewers, 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.
Concept ACK
It's easier to read and maintain the code this way imo.
Approach ACK
Adding the unit makes the code more readable (in the same way that using std::chrono instead of int makes the code better)
117 | @@ -118,6 +118,8 @@ using node::nPruneTarget; 118 | static const bool DEFAULT_PROXYRANDOMIZE = true; 119 | static const bool DEFAULT_REST_ENABLE = false; 120 | 121 | +static constexpr size_t MIB_BYTES = 1024 * 1024;
This will force all places where this is used to uint64_t, even if they are supposed to be signed integers. Not sure, but maybe a #define or int type is better, so that the sign of the surrounding code is chosen?
Ouch, good point. I'm starting to doubt this change now.
Thanks @MarcoFalke, this was indeed surprising to me:
Otherwise, if the unsigned operand's conversion rank is greater or equal to the conversion rank of the signed operand, the signed operand is converted to the unsigned operand's type.
https://en.cppreference.com/w/cpp/language/operator_arithmetic#Conversions
I updated the PR to use int32_t for these constants, on the theory that int being the smallest value for an unsuffixed literal field, these values would be equivalent to the inline arithmetic.
https://en.cppreference.com/w/cpp/language/integer_literal#The_type_of_the_literal
Though I maintain uint64_t for GB_BYTES to maintain protections against overflow in PruneGBtoMiB.
In an effort to validate these concerns, I ran build with -Wsign-conversion and -Wsign-compare, with the new and old code, and did not see any warnings relative to MIB_BYTES, MIN_PRUNE_TARGET_GB, or _FOR_BLOCK_FILES. I also reviewed each impacted line and did not identify such issues.
Prior, uint64_t code here: https://github.com/Empact/bitcoin/commits/2022-06-mib-bytes-sign-conversion-test
Current, int32_t code here: https://github.com/Empact/bitcoin/commits/2022-06-mib-bytes-sign-conversion
Co-authored-by: benthecarman <benthecarman@live.com>
Co-authored-by: Justin Litchfield <litch@me.com>
Co-authored-by: Liran Cohen <c.liran.c@gmail.com>
Co-authored-by: Ryan Loomba <ryan.loomba@gmail.com>
Co-authored-by: Buck Perley <bucko.perley@gmail.com>
Co-authored-by: bajjer <bajjer@bajjer.xyz>
Co-authored-by: Suhail Saqan <suhail.saqan@gmail.com>
Co-authored-by: Christopher Sweeney <sweeney.chris@gmail.com>
Co-authored-by: Alyssa <orbitalturtle@protonmail.com>
Co-authored-by: Ben Schroth <ben@styng.social>
Co-authored-by: Jason Hester <mail@jason-hester.me>
Co-authored-by: Matt Clough <Matt.clough@pm.me>
Co-authored-by: Elise Schedler <eliseschedler@gmail.com>
Co-authored-by: ghander <cen254@gmail.com>
Co-authored-by: PopeLaz <btclz@fastmail.com>
cc @mzumsande
This requires creating a non-gui analog to guiconstants.h, and
lifting GB/MIB_BYTES and MIN_*_FOR_BLOCK_FILES into it.
462 | @@ -463,6 +463,8 @@ if test "$CXXFLAGS_overridden" = "no"; then 463 | [AC_LANG_SOURCE([[struct A { virtual void f(); }; struct B : A { void f() final; };]])]) 464 | AX_CHECK_COMPILE_FLAG([-Wunreachable-code-loop-increment], [WARN_CXXFLAGS="$WARN_CXXFLAGS -Wunreachable-code-loop-increment"], [], [$CXXFLAG_WERROR]) 465 | AX_CHECK_COMPILE_FLAG([-Wimplicit-fallthrough], [WARN_CXXFLAGS="$WARN_CXXFLAGS -Wimplicit-fallthrough"], [], [$CXXFLAG_WERROR]) 466 | + AX_CHECK_COMPILE_FLAG([-Wsign-compare], [WARN_CXXFLAGS="$WARN_CXXFLAGS -Wsign-compare"], [], [$CXXFLAG_WERROR]) 467 | + AX_CHECK_COMPILE_FLAG([-Wsign-conversion], [WARN_CXXFLAGS="$WARN_CXXFLAGS -Wsign-conversion"], [], [$CXXFLAG_WERROR])
This leads to lots of warnings all over the place for me (unrelated to MIB_BYTES). I don't think it should be part of this PR:
9 | + 10 | +/* One gigabyte (GB) in bytes */ 11 | +static constexpr uint64_t GB_BYTES{1000000000}; 12 | + 13 | +/* One mebibyte (MiB) in bytes */ 14 | +static constexpr int32_t MIB_BYTES{1024 * 1024};
How about introducing this right from the beginning? It's a bit weird that MIB_BYTES jumps files with each commit, from init.cpp to validation.h to its final destination constants.h.
Concept ACK.
git grep "1024 / 1024" shows a few more spots that could make use of the constant.
<!--cf906140f33d8803c4a75a2196329ecb-->
🐙 This pull request conflicts with the target branch and needs rebase.
Closing this as it has not had any activity in a while. If you are interested in continuing work on this, please leave a comment so that it can be reopened.