Skip to content
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

gh-120593: Fix const qualifier in pyatomic.h #121052

Closed
wants to merge 1 commit into from

Conversation

vstinner
Copy link
Member

@vstinner vstinner commented Jun 26, 2024

Remove the 'const' qualifier of the argument of functions:

  • _Py_atomic_load_ptr()
  • _Py_atomic_load_ptr_relaxed()
  • _Py_atomic_load_ptr_acquire()

Remove the 'const' qualifier of the argument of functions:

* _Py_atomic_load_ptr()
* _Py_atomic_load_ptr_relaxed()
* _Py_atomic_load_ptr_acquire()
@vstinner vstinner changed the title gh-120593: Fix const qualified in pyatomic.h gh-120593: Fix const qualifier in pyatomic.h Jun 26, 2024
Copy link
Contributor

@picnixz picnixz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if you like when we comment on a draft so feel free to ignore my comment!

{ return (void *)__atomic_load_n((void **)obj, __ATOMIC_ACQUIRE); }

static inline uintptr_t
_Py_atomic_load_uintptr_acquire(const uintptr_t *obj)
{ return (uintptr_t)__atomic_load_n((uintptr_t *)obj, __ATOMIC_ACQUIRE); }
{ return (uintptr_t)__atomic_load_n(obj, __ATOMIC_ACQUIRE); }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this change. Shouldn't you rather remove the const from the signature?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without this change, the compiler emits a warning.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but isn't it because the object being passed to _Py_atomic_load_uintptr_acquire is a const uintptr_t *?

Now that I look a bit around, all the signatures take a const T * but I'm not sure if it's better to remove the inner cast or to fix the cast itself.

For instance,

static inline void *
_Py_atomic_load_ptr_acquire(const void *obj)
{ return (void *)__atomic_load_n((void **)obj, __ATOMIC_ACQUIRE); }

could be fixed as

static inline void *
_Py_atomic_load_ptr_acquire(const void *obj)
{ return (void *)__atomic_load_n((void * const*)obj, __ATOMIC_ACQUIRE); }

instead of changing the signature from const void * to void * (also, the cast on the return type should not needed I think). What do you think of that? at least, we would keep the same logic for signatures.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but isn't it because the object being passed to _Py_atomic_load_uintptr_acquire is a const uintptr_t *?

The compiler warns if you cast from "const TYPE" to "TYPE". My change removes the cast. It just works.

instead of changing the signature from const void * to void *

void* is special. I gave up trying to fix the warning, so I changed the parameters type of the 3 "pointer" functions instead.

Did you try your proposed fix? When I tried, it didn't work for me.

Copy link
Contributor

@picnixz picnixz Jun 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well yes, it worked for me actually.. that's why I suggested it. I changed this:

// L491 in pyatomic_gcc.h
static inline void *
_Py_atomic_load_ptr_acquire(const void *obj)
{ return (void *)__atomic_load_n((void **)obj, __ATOMIC_ACQUIRE); }

into

static inline void *
_Py_atomic_load_ptr_acquire(const void *obj)
{ return __atomic_load_n((void * const*)obj, __ATOMIC_ACQUIRE); }

and I did not have any warning for this specific function (there were more but not for this one) (I also tried with a cast on the return and the warning still did not appear).

My GCC version is 7.5.0 by the way.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I tried const void * const *, I don't recall.

Anyway, I wrote a new PR instead: PR gh-121055.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I tried const void * const *,

It's highly possible because the first fix I suggested on the issue was actually with a return type of const void * and not void * (hence the const void * const *). So it's partly my fault!

Copy link
Member Author

@vstinner vstinner Jun 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your nice advice, it worked well at the end 😉

@vstinner vstinner added the needs backport to 3.13 bugs and security fixes label Jun 26, 2024
@vstinner vstinner marked this pull request as ready for review June 26, 2024 16:00
@vstinner
Copy link
Member Author

@colesbury: Would you be ok with these changes to avoid compiler warnings with -Wcast-qual? Or does it look suspicious to you?

cc @pitrou

@pitrou
Copy link
Member

pitrou commented Jun 26, 2024

Why not use something like this instead of removing the const qualifiers altogether?

@colesbury
Copy link
Contributor

colesbury commented Jun 26, 2024

I don't think we should remove the const qualifiers. They are useful for the load functions both to signify to callers that we don't modify the value and to avoid extra casts at the call sites.

My preference in rough order is:

  • We should fix the cast qualifiers when possible, like @pitrou suggests
  • We shouldn't be chasing useless warning safety, like -Wcast-qual when it makes our headers worse. People shouldn't be applying their project's warnings to Python.h. I forget if this is just a matter of #include <Python.h> (vs. #include "Python.h") or something else.
  • Or finally, suppress the warnings with the appropriate #pragma gcc directive in pyatomic_gcc.h

@vstinner
Copy link
Member Author

I don't think we should remove the const qualifiers.

Ok, I abandon this PR in favor of a different approach: PR gh-121055.

@vstinner vstinner closed this Jun 26, 2024
@vstinner vstinner deleted the pyatomic_remove_const branch June 26, 2024 17:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants