Page MenuHomePhabricator

[64-bit ints] Refactor `CScriptNum` to require setting `nMaxNumSize`
ClosedPublic

Authored by tobias_ruck on Oct 25 2024, 00:21.

Details

Summary

Currently, CScriptNum's constructor and IsMinimallyEncoded have a default for nMaxNumSize, which defaults to 4 (eCash's maximum integer size).

For upgrading Script integers from 32-bit to 64-bit, having to make the integer size explicit allows us to upgrade them based on a script flag.

This has no change in behavior.

Test Plan

ninja check

Diff Detail

Repository
rABC Bitcoin ABC
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

rebase, also do the same change with ScriptNum10

Fabien requested changes to this revision.Dec 6 2024, 13:43
Fabien added inline comments.
src/script/script.h
227 ↗(On Diff #51430)

This should probably no longer be a CScriptNum member. Why would you pass a static member to the constructor ?

When going from 4 to 8 this variable will need to be moved out anyway.

This revision now requires changes to proceed.Dec 6 2024, 13:43
src/script/script.h
227 ↗(On Diff #51430)

well we can just reference CScriptNum::MAXIMUM_ELEMENT_SIZE, no?

but happy to move it, keep it inside script.h ?

keep in mind that there will be two variables during transition, MAXIMUM_ELEMENT_SIZE_32_BIT and MAXIMUM_ELEMENT_SIZE_64_BIT

move MAX_ELEMENT_SIZE out of CScriptNum, rename to MAX_SCRIPTNUM_BYTE_SIZE

src/core_write.cpp
125 ↗(On Diff #55082)

Can %d from tinyformat handle 64 bits integers ? If not this will become an issue after you set MAX_SCRIPTNUM_BYTE_SIZE to 8

This revision is now accepted and ready to land.Aug 1 2025, 18:38
src/core_write.cpp
125 ↗(On Diff #55082)

we already rely on the behavior you mention, PackageToValidate::ToString uses it on a int64_t (NodeId is a typedef for it), so should be fine