diff options
author | fanquake <fanquake@gmail.com> | 2019-08-21 15:06:21 +0800 |
---|---|---|
committer | fanquake <fanquake@gmail.com> | 2019-08-21 15:25:59 +0800 |
commit | 01ebaa05a4872f3cf29745b3a51777cd5fe7af82 (patch) | |
tree | 56bc0b4a1f523a937b7ff9110deb8811e3f98bba /src/wallet/coincontrol.cpp | |
parent | 8ee572f0940bbf1823e946ec507c5fe46db90fb8 (diff) | |
parent | 2dbfb37b407ed23b517f507d78fb77334142dce5 (diff) |
Merge #16572: wallet: Fix Char as Bool in Wallet
2dbfb37b407ed23b517f507d78fb77334142dce5 Fix Char as Bool in interfaces (Jeremy Rubin)
Pull request description:
In a few places in src/wallet/wallet.h, we use a char when semantically we want a bool.
This is kind of an issue because it means we can unserialize the same transaction with different fFromMe flags (as differing chars) and evaluate the following section in wallet/wallet.cpp
```c++
if (wtxIn.fFromMe && wtxIn.fFromMe != wtx.fFromMe)
{
wtx.fFromMe = wtxIn.fFromMe;
fUpdated = true;
}
```
incorrectly (triggering an fUpdated where both fFromMe values represent true, via different chars).
I don't think this is a vulnerability, but it's just a little messy and unsemantic, and could lead to issues with stored wtxIns not being findable in a map by their hash.
The serialize/unserialize code for bool internally uses a char, so it should be safe to make this substitution.
NOTE: Technically, this is a behavior change -- I haven't checked too closely that nowhere is depending on storing information in this char. Theoretically, this could break something because after this change a tx unserialized with such a char would preserve it's value, but now it is converted to a ~true~ canonical bool.
ACKs for top commit:
achow101:
Code review ACK 2dbfb37b407ed23b517f507d78fb77334142dce5
meshcollider:
Code review ACK 2dbfb37b407ed23b517f507d78fb77334142dce5
Tree-SHA512: 8c0dc9cf672aa2276c694facbf50febe7456eaa8bf2bd2504f81a61052264b8b30cdb5326e1936893adc3d33504667aee3c7e207a194c71d87b3e7b5fe199c9d
Diffstat (limited to 'src/wallet/coincontrol.cpp')
0 files changed, 0 insertions, 0 deletions