-
Notifications
You must be signed in to change notification settings - Fork 9
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
Inlined functions from CPython API #55
Comments
Thanks @karlotness! Yeah, there's a good chance that Those static inline functions are an interesting case -- I think you're right that they alone shouldn't be considered an ABI violation, since they can appear when their implementation is solely the stable ABI implementation. Do you have a shared object/Python wheel I can test with? |
Thanks for taking a look. Here's one I was testing with (attached), built from here at adrt-1.0.0.dev0-cp310-abi3-linux_x86_64.whl.zip I did patch the limited api definition to |
Closing in favor of #85, where we'll be tracking a general fix for this! |
Thanks for the project, seems like a very useful tool and it's nice to have it to check things over.
I notice in the README you mention that abi3audit also checks symbols for inlined non-exported functions (giving
_Py_DECREF
) as an example. I think I've run into some issues with those checks.In particular, I think there may be an issue with the tool flagging some functions that are part of the limited API and implemented as static inline functions vs. those which are imported from CPython and part of the stable ABI (and explicitly listed in the manifest).
I wonder if the checks looking at
symtab
might be too strict?For example, I've tested this on a limited ABI wheel, that sets the
Py_LIMITED_API
macro. If I disable optimizations (to keep functions from being inlined) I see errors for:_Py_INCREF
_Py_DECREF
_Py_IS_TYPE
which, from what I can tell, are implemented in Python 3.10 as static inline functions (and were in 3.8 as well)
It does seem like CPython anticipates these being used in limited API modules even if they aren't in the manifest.
A bit of digging on those trying to double check:
_Py_INCREF
and_Py_DECREF
have preprocessor conditions internally depending on the limited API state in Python 3.10. ThePy_{INC,DEC}REF
macros are also mentioned in PEP683 as a consideration for implementing immortal objects and the_Py_{INC,DEC}REF
are part of their inlined implementations.The
_Py_IS_TYPE
comes from a few places: such as a use ofPyCapsule_CheckExact
(where the*_Check
macros are mentioned in PEP 384) andPyObject_TypeCheck
(which is implemented withPy_IS_TYPE
andPyType_IsSubtype
which is part of the limited ABI).Py_IS_TYPE
also gets special limited API handling on the current main branch.Thanks again!
The text was updated successfully, but these errors were encountered: