Repository navigation
Uninitialized variable replace usage in charmapencode_output (Objects/unicodeobject.c) discovered by scan-build #146429
Description
Bug report
Bug description:
Static analysis with scan-build points to a potential use of an uninitialized variable in Objects/unicodeobject.c, specifically within the charmapencode_output function.
The variable unsigned char replace is declared on the stack without initialization. It is passed by reference to charmapencode_lookup(&replace). Later, inside the if (PyLong_Check(rep)) block, replace is cast and assigned to the output buffer:
outstart[(*outpos)++] = (char)replace; // scan-build: Assigned value is uninitializedIf charmapencode_lookup returns a valid PyLong object but fails to update the reference to replace (or purely from a static analysis perspective), this leads to reading uninitialized stack memory.
Suggested Fix:
Either initialize replace upon declaration or retrieve the value directly from the rep object, which is guaranteed to be a PyLong in that scope:
// Instead of using 'replace':
outstart[(*outpos)++] = (char)PyLong_AsLong(rep);CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Activity
vstinner commentedon Mar 25, 2026
What is scan-build? Is it a static analyzer?
I don't understand the "fails to update the reference to replace" part.
If charmapencode_lookup() returns a Python int (if
PyLong_Check()is true), replace is initialized and so it's safe to use it.I don't see any code path where replace is used whereas it's not initialized. It looks like a false-alarm of a static analyzer to me.
ashm-dev commentedon Mar 25, 2026
@vstinner
scan-buildis the standard command-line utility for the Clang Static Analyzer (LLVM project). It essentially runsclang --analyze.Even if
charmapencode_lookupguarantees writing toreplace(making this a false positive for now), the compiler cannot verify this invariant. This leaves the code fragile:charmapencode_lookupcould silently break this implicit contract, introducing UB.Zero-cost initialization (
unsigned char replace = 0;) fixes the warning and future-proofs the code.vstinner commentedon Mar 25, 2026
I'm not sure that it has a zero-cost. We don't have to fix all false-alarms triggered by the various static analyzers.
cc @serhiy-storchaka who modified
charmapencode_lookup()recently.I suggest closing this issue as "won't fix".
serhiy-storchaka commentedon Mar 26, 2026
I agree with @vstinner. This is a problem of the static analyzing tool.
The code is not simple, and I do not see a way to rewrite it in significantly simpler way. An attempt to rewrite is the event that can introduce a bug. Adding initialization to silence the static analyzer complain can hide future bugs.