Because we know in both cases they don't hold a negative value, simply cast to unsigned.
Fix two warnings for comparison between signed and unsigned #8172
pull sipa wants to merge 1 commits into bitcoin:master from sipa:fixunsigned changing 2 files +2 −2-
sipa commented at 1:45 PM on June 8, 2016: member
-
Fix two warnings for comparison between signed and unsigned 77f63a4fcd
-
jonasschnelli commented at 1:46 PM on June 8, 2016: contributor
Finally someone did this. :-)
Thanks. utACK 77f63a4fcd0517a6804bde7285e1859d5a087d77
- jonasschnelli added the label Refactoring on Jun 8, 2016
-
laanwj commented at 1:53 PM on June 8, 2016: member
-
MarcoFalke commented at 2:01 PM on June 8, 2016: member
Even if it was negative, we'd get an huge unsigned value which is greater than
vout.size().utACK 77f63a4
-
MarcoFalke commented at 2:02 PM on June 8, 2016: member
Fixes #7889?
-
paveljanik commented at 6:06 PM on June 8, 2016: contributor
-
-
laanwj commented at 5:27 AM on June 9, 2016: member
Nit: should we phase out C-style casts? In this case it's obviously just a static_cast, but I think it would be safer to use new-style casts in all new code. I wrote a PR for the developer docs: #8177
I've never seen an argument that made c++ style casts safer for this kind of usage. It's much shorter to write C-style casts if you just want to, say, convert a signed integer to an unsigned one, and sometimes this is done quite a few times per line so c++ syntax would be messy.
(the static cast versus dynamic cast versus reinterpret cast safety seems to apply to pointers and objects)
- laanwj merged this on Jun 9, 2016
- laanwj closed this on Jun 9, 2016
- laanwj referenced this in commit 7e6dd7bee4 on Jun 9, 2016
- codablock referenced this in commit ddff6d6e6e on Sep 16, 2017
- codablock referenced this in commit 0ff28494f0 on Sep 19, 2017
- codablock referenced this in commit cfc76bab9a on Dec 22, 2017
- andvgal referenced this in commit 4d2988cb2e on Jan 6, 2019
- MarcoFalke locked this on Sep 8, 2021
Contributors
Labels