Repository navigation
pyatomic_gcc.h with GCC discards const qualifier #120593
Description
Activity
- addedtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
on Jun 16, 2024 For the record, this is not the only place where const qualifiers are lost. If you compile cpython with
make CFLAGS=-Wcast-qual -j12you end up with a lot of warnings. For the line 359, the fix would be:// pyatomic_gcc.h static inline void * _Py_atomic_load_ptr_relaxed(const void *obj) -{ return (void *)__atomic_load_n((void **)obj, __ATOMIC_RELAXED); } +{ return (void *)__atomic_load_n((void * const *)obj, __ATOMIC_RELAXED); }
As you can see you lose constness twice, namely when calling
__atomic_load_nand when returning the type. Note that we have// pyatomic_std.h static inline void * _Py_atomic_load_ptr_relaxed(const void *obj) { _Py_USING_STD; return atomic_load_explicit((const _Atomic(void*)*)obj, memory_order_relaxed); }
As you can see, the cast here is essentially using a
const void **, but still the return type should be a const as well (in the case of__atomic_load_n, the signature istype __atomic_load_n(type *ptr, int memorder);).EDIT: I edited my comment in order to reflect the real signature of
_Py_atomic_load_ptr_relaxedin cpython. The return type is avoid *and not aconst void *but the inner cast fix remains correct.Yes, I'd like to clarify that this is specifically not about compiling CPython, it's about including Python.h only.
Yes, I understood that from the other issue but since you only mentioned 2 lines, I wanted to 1) give a way to fix it 2) say that it's not just 2 lines that are affected but a lot of calls.
Reacted by n.d. parker- changed the title
[-]Python.h with GCC discards const qualifier [/-][+]pyatomic_gcc.h with GCC discards const qualifier [/+]on Jun 26, 2024 - addedneeds backport to 3.13only security fixesonly security fixesand removedneeds backport to 3.13only security fixesonly security fixes
on Jun 26, 2024 2 remaining items
I don't think weakening the type of calls that should be
constis the correct thing to do here.
Where there is a conflict in types we should be strengthening the type, not weakening it.
Why not strengthen the types in the callees, rather than weakening them in the callers?I don't think weakening the type of calls that should be const is the correct thing to do here.
If you're talking about _PyLong_CompactValue(): I wrote PR gh-122367 to restore the const modifier.
If you're talking about something else, please elaborate which function/code you are referring to.
Bug report
Bug description:
Hi,
including Python.h with gcc and -Wcast-qual raises the following issue (Regression from 3.12):
This is a follow-up to #120293
CPython versions tested on:
3.13
Operating systems tested on:
Linux
Linked PRs