Skip to content

Conversation

@Empact
Copy link
Contributor

@Empact Empact commented Jun 16, 2022

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.

@laanwj
Copy link
Member

laanwj commented Jun 16, 2022

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.

@DrahtBot
Copy link
Contributor

DrahtBot commented Jun 16, 2022

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.

Type Reviewers
Concept ACK laanwj, brunoerg, mzumsande
Approach ACK w0xlt

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #26674 (Add reindex=auto flag to automatically reindex corrupt data by AaronDewes)
  • #26288 (Enable -Wstring-concatenation and -Wstring-conversion on clang builds by Empact)
  • #25972 (build: no-longer disable WARN_CXXFLAGS when CXXFLAGS is set by fanquake)
  • #25781 (Remove almost all blockstorage globals by MarcoFalke)
  • #25361 (BIP324: Cipher suite by dhruv)
  • #23233 (BIP324: Add encrypted p2p transport {de}serializer by dhruv)

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.

Copy link
Contributor

@brunoerg brunoerg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK

It's easier to read and maintain the code this way imo.

Copy link
Contributor

@w0xlt w0xlt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

src/init.cpp Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ouch, good point. I'm starting to doubt this change now.

Copy link
Contributor Author

@Empact Empact Oct 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though I maintain uint64_t for GB_BYTES to maintain protections against overflow in PruneGBtoMiB.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Empact and others added 2 commits October 10, 2022 14:32
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>
@Empact Empact force-pushed the 2022-06-mib-bytes branch 3 times, most recently from 98b8176 to 6b64215 Compare October 10, 2022 18:59
@achow101
Copy link
Member

cc @mzumsande

This requires creating a non-gui analog to guiconstants.h, and
lifting GB/MIB_BYTES and MIN_*_FOR_BLOCK_FILES into it.
@Empact Empact force-pushed the 2022-06-mib-bytes branch from 6b64215 to 86e1d59 Compare October 12, 2022 20:07
Copy link
Contributor

@mzumsande mzumsande left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK.

git grep "1024 / 1024" shows a few more spots that could make use of the constant.

AX_CHECK_COMPILE_FLAG([-Wunreachable-code-loop-increment], [WARN_CXXFLAGS="$WARN_CXXFLAGS -Wunreachable-code-loop-increment"], [], [$CXXFLAG_WERROR])
AX_CHECK_COMPILE_FLAG([-Wimplicit-fallthrough], [WARN_CXXFLAGS="$WARN_CXXFLAGS -Wimplicit-fallthrough"], [], [$CXXFLAG_WERROR])
AX_CHECK_COMPILE_FLAG([-Wsign-compare], [WARN_CXXFLAGS="$WARN_CXXFLAGS -Wsign-compare"], [], [$CXXFLAG_WERROR])
AX_CHECK_COMPILE_FLAG([-Wsign-conversion], [WARN_CXXFLAGS="$WARN_CXXFLAGS -Wsign-conversion"], [], [$CXXFLAG_WERROR])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

static constexpr uint64_t GB_BYTES{1000000000};

/* One mebibyte (MiB) in bytes */
static constexpr int32_t MIB_BYTES{1024 * 1024};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@DrahtBot
Copy link
Contributor

🐙 This pull request conflicts with the target branch and needs rebase.

@achow101
Copy link
Member

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.

@achow101 achow101 closed this Apr 25, 2023
@bitcoin bitcoin locked and limited conversation to collaborators Apr 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants