-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
gh-132314: fix stack array init warning #132376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
There was no warning with the configuration without options, but I reproduced it with the --enable-optimization --with-lto options. The mistake is very simple. |
Python/ceval.c
Outdated
@@ -1814,7 +1814,7 @@ _PyEvalFramePushAndInit_Ex(PyThreadState *tstate, _PyStackRef func, | |||
PyObject *kwnames = NULL; | |||
_PyStackRef *newargs; | |||
PyObject *const *object_array = NULL; | |||
_PyStackRef stack_array[8]; | |||
_PyStackRef stack_array[8] = {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO, the compiler warning is a false-positive.
If the stack_array
is used
Lines 1832 to 1834 in ad3bbe8
if (nargs <= 8) { | |
newargs = stack_array; | |
} |
it is initialized
Lines 1844 to 1846 in ad3bbe8
for (Py_ssize_t i = 0; i < nargs; i++) { | |
newargs[i] = PyStackRef_FromPyObjectNew(PyTuple_GET_ITEM(callargs, i)); | |
} |
Having a small array on the stack to avoid the PyMem_Malloc
is a common pattern, e.g. further down
Line 1880 in ad3bbe8
_PyStackRef stack_array[8]; |
or like mentioned in the issue #132314
Line 1450 in ad3bbe8
PyObject *small_stack[_PY_FASTCALL_SMALL_STACK]; |
They all follow the same pattern, and if the compiler is not smart enough to detect it, it will issue a warning.
IMHO, initializing those stack variables using = {}
is a waste of CPU cycles, and we should silence the warning using a diagnostic pragma.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think hiding warnings using pragma it is not good idea, because we have other compilers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, but not all of them emit the warning, so we only have to silence those that do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes and we can selectively decide which compilers need to be silenced as well so I think for a falsey positive like that it's better to silence the warning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. Check please new version. @chris-eibl @picnixz
Add macros to disable and re-enable compiler-specific warnings about possibly uninitialized variables (`-Wmaybe-uninitialized` for GCC, `-Wuninitialized` for Clang, and warning C4700 for MSVC). Use these macros in `_PyEvalFramePushAndInit_Ex()` to suppress false positives on stack-allocated arrays like `stack_array`. This also addresses warnings such as the one in `pycore_call.h` when using `small_stack[_PY_FASTCALL_SMALL_STACK]` that may be flagged by GCC's `-Wmaybe-uninitialized`.
Dummy warning fix