Ava Chow bb90899955 Merge bitcoin/bitcoin#34435: refactor: use _MiB/_GiB consistently for byte conversions ...

af0ee28eb6 refactor: use _MiB consistently for Mebibyte conversions (Lőrinc)
b3edd30aa2 util: add _GiB for Gibibyte conversions (Lőrinc)

Pull request description:

  ### Problem
  Byte-size conversions in the codebase currently show up in many equivalent formats (multiplication/division chains, shifts, hex/binary literals), which creates a maintenance burden and makes review error-prone - especially considering the architectural differences of `size_t`.
  Inspired by https://github.com/bitcoin/bitcoin/pull/34305#discussion_r2734720002, it seemed appropriate to unify `Mebibyte` usage across the codebase and add `Gibibyte` support with 32/64 bit `size_t` validation.

  ### Fix
  This PR refactors those call sites to use `""_MiB` (existing) and `""_GiB` (new), and adds the encountered value/pattern replacements to unit tests to make review straightforward, and to ensure the conversions remain valid.
  The literals are overflow-checked when converting to `size_t`, and unit tests cover the 32-bit boundary cases.

  Concretely, it replaces patterns such as:
  * `1024*1024`, `1<<20`, `0x100000`, `1048576`, `/ 1024 / 1024`, `* (1.0 / 1024 / 1024)` → `1_MiB` or `double(1_MiB)`
  * `1024*1024*1024`, `1<<30`, `0x40000000`, `1024_MiB`, `>> 30` → `1_GiB`

  (added unit tests for each replacement category to ease review)

  Additionally, declarations whose initializer reads a `_MiB`/`_GiB` literal are switched to braced initialization so a future oversized value is rejected at compile time through the narrowing check instead of silently truncating.

  ### Note
  In the few places where arithmetic involves signed values, the result is identical to the previous code assuming those quantities never become negative.

ACKs for top commit:
  achow101:
    ACK af0ee28eb6
  janb84:
    ACK af0ee28eb6
  maflcko:
    review ACK af0ee28eb6 🖍
  hodlinator:
    re-ACK af0ee28eb6

Tree-SHA512: 55286ce3f833f88335394a74e9e0b95c7d023e5cdc9ded40accbbbcd870101e4dcc05926865d6bef4c1be1ebd648aa3fdf947ef9575633ccfe56691f145d7a2d

2026-04-22 15:37:59 -07:00

50 KiB

Raw Blame History

View Raw