Skip to content

all: print unsigned values with unsigned conversions - #410

Open
xanimo wants to merge 1 commit into
dogecoinfoundation:0.1.5-devfrom
xanimo:0.1.5-dev-printf-formats
Open

all: print unsigned values with unsigned conversions#410
xanimo wants to merge 1 commit into
dogecoinfoundation:0.1.5-devfrom
xanimo:0.1.5-dev-printf-formats

Conversation

@xanimo

@xanimo xanimo commented Aug 6, 2026

Copy link
Copy Markdown
Member

cppcheck reports eighteen invalidPrintfArgType_sint findings — %d used with unsigned arguments across block.c, headersdb_file.c, spv.c, validation.c, wallet.c, such.c, spvnode.c and tool.c.

None of them misbehave for the values these actually carry. A height or a merkle index would have to exceed INT_MAX to print wrong. So this is correctness, not a bug fix, and I'd rather say that up front than dress it up.

It's worth doing anyway for two reasons.

It's most of what stands between the cppcheck gate and the level its own header says it should reach:

Gating widens to warning once the initial backlog is dispositioned in cppcheck-suppressions.txt

And a suppression would have been the wrong tool. The suppressions file is for false positives with a written reason. These are real findings — just harmless ones. Suppressing them is how a gate quietly stops meaning anything.

Choices

uint32_t fields use PRIu32 rather than %u. The tree already uses the PRI macros in koinu.c, net.c and wallet.c, and it states the width at the call site instead of relying on unsigned int and uint32_t happening to agree. Plain unsigned int loop counters use %u. inttypes.h added where PRIu32 is now used and wasn't already included.

dogecoin_bool arguments were deliberately left alone — it's a uint8_t, which promotes to int, so %d is already correct there, and cppcheck doesn't flag them. Changing those would have been noise.

Where this leaves the backlog

Local cppcheck: 34 warnings → 16. The remainder is already covered by open work:

Remaining Covered by
4 nullPointerRedundantCheck + 2 ctunullpointer #404
2 negativeIndex (qr.c), 1 invalidscanf (bip39) #401
2 uninitvar (OP-TEE false positives) #403 suppressions
4 internalAstError cppcheck 2.7 parser limits — absent on the 2.13 the CI image ships

So with #401, #403, #404 and this, the phase-1 backlog is essentially clear and the gate can widen to warning as intended.

81/81.

cppcheck reports eighteen invalidPrintfArgType_sint findings: %d used
with unsigned arguments across block.c, headersdb_file.c, spv.c,
validation.c, wallet.c, such.c, spvnode.c and tool.c.

None of them misbehave for the values these actually carry -- a height or
a merkle index would have to exceed INT_MAX to print wrong -- so this is
correctness rather than a bug fix. It is worth doing anyway, because
these eighteen are most of what stands between the cppcheck gate and the
warning level its own header says it should reach:

    Gating widens to `warning` once the initial backlog is dispositioned

and because a suppression would have been the wrong way to clear them.
The suppressions file is for false positives with a written reason; these
are real, just harmless.

uint32_t fields use PRIu32 rather than %u. The tree already uses the PRI
macros in koinu.c, net.c and wallet.c, and it states the width at the
call site instead of relying on unsigned int and uint32_t happening to
agree. Plain unsigned int loop counters use %u. inttypes.h is added where
PRIu32 is now used and was not already included.

dogecoin_bool arguments were left alone: it is a uint8_t, which promotes
to int, so %d is already correct for those and cppcheck does not flag
them.

Local cppcheck goes from 34 warnings to 16, and the remainder is covered
by work already open: the null-check findings by dogecoinfoundation#404, the qr.c
negativeIndex and bip39 invalidscanf by dogecoinfoundation#401, and the OP-TEE uninitvar
false positives by dogecoinfoundation#403's suppressions. The internalAstError hits are
cppcheck 2.7 parser limits and do not appear on the 2.13 the CI image
ships.

81/81.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant