PyConfig_Set() and sys.set_int_max_str_digits() now replace
sys.flags (create a new object), instead of modifying sys.flags in-place.
Modifying sys.flags in-place can lead to data races when multiple
threads are reading or writing sys.flags in parallel.
Use _Py_atomic functions to get and set max_str_digits members.
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
The guard that skips the "chown to gid 0 should fail" assertion used
only `os.getgroups()` (supplementary groups). The kernel also accepts
the effective/filesystem gid for chown, so when a process runs with
egid 0 and a non-zero uid (common in containers and user namespaces),
chown(-1, 0) succeeds and the assertion spuriously fails.
Add an `os.getegid() != 0` check alongside the existing
`0 not in os.getgroups()` guard.
* snprintf() is not async-signal-safe: replace it with
_Py_DumpDecimal().
* Fix tid type from 'long' to 'unsigned long'.
* Replace PyLong_AsLong() with PyLong_AsInt().
* Avoid unnecessary narrowing cast on _Py_write_noraise() call.
Call PyBuffer_Release() if PyObject_GC_New() fails.
Fix also bytes_join(): only call Py_DECREF(item) after formatting the
error message which uses item.
Replace also _PyObject_HashFast() with PyObject_Hash()
in _collections._count_elements().
Rename _PyObject_HashFast() to _PyObject_HashDictKey(),
and mark it as Py_ALWAYS_INLINE.
Only use _PyObject_HashDictKey() on dictionaries.
Since the recursion guard tracks real C-stack bounds (gh-91079), this test
asserts that 500k nesting levels overflow the stack margin. On a 64 MiB stack
(some Nix build envs use one that large), the optimized interpreter uses ~160
bytes/level (raises at ~420k levels) so the assertion holds with only ~16%
margin; the PGO *instrumented* stage inlines less, its per-level scanner frames
are smaller, and the 500k-deep decode completes -- "RecursionError not raised"
fails the profile run and aborts `make profile-opt`. Upstream's
skip_if_unlimited_stack_size (gh-143460) only covers RLIM_INFINITY, not
large-finite stacks like ours.
We could also keep playing whack a mole and raise the 500k to a much larger
number... but there's little value in PGO training on this test anyways.
The standard says that a call to `memcpy` must pass a valid source and
destination pointer even if the size is 0, so we must avoid calling
`memcpy` when our source pointer is NULL. If we don't, an optimizing
compiler can decide that the pointer must be non-NULL based on the
presence of UB, and optimize out checks for null pointers.
Specifically, note that the standard says:
Where an argument declared as size_t n specifies the length of the
array for a function, n can have the value zero on a call to that
function. Unless explicitly stated otherwise in the description of
a particular function in this subclause, pointer arguments on such
a call shall still have valid values, as described in 7.1.4.
And section 7.1.4 says:
If an argument to a function has an invalid value (such as a value
outside the domain of the function, or a pointer outside the address
space of the program, or a null pointer, or a pointer to
non-modifiable storage when the corresponding parameter is not
const-qualified) or a type (after default argument promotion) not
expected by a function with a variable number of arguments, the
behavior is undefined.
The specification for `memcpy` doesn't state that it's allowed to be
called with null pointers, and Linux's `/usr/include/string.h` declares
`memcpy` as `__nonnull ((1, 2))`.
Append parsed values to the result list with _PyList_AppendTakeRef and
insert key/value pairs with _PyDict_SetItem_Take2, which take ownership of
the references instead of incref-ing on insert and then decref-ing the
local. This removes a reference-count round-trip per element (and, on the
free-threaded build, a per-append lock).
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
