> requires some newer tools like -fvisibility=hidden that work
> differently across different platforms, and so far no-one's done the
> work to sort out the details.
I've started looking at this, but quite apart from the specifics of applying
-fvisibility=hidden, there are some things that aren't yet clear to me about
the intent behind some of our symbol definitions. For example, the file
Include/fileutils.h contains the definitions
PyAPI_FUNC(wchar_t *) Py_DecodeLocale(const char *arg, size_t *size);
and
PyAPI_FUNC(int) _Py_DecodeLocaleEx(const char *arg,
wchar_t **wstr,
size_t *wlen,
const char **reason,
int current_locale,
_Py_error_handler errors);
However, only the first of these is documented, though the definition via
PyAPI_FUNC implies that both are part of the public API. If this is the case,
why aren't both documented? If _Py_DecodeLocaleEx is not part of the public API
(and the leading underscore suggests so), should it be polluting the symbol
space?
The comment for PyAPI_FUNC is "Declares a public Python API function and return
type". Is this really the case, or has PyAPI_FUNC been coopted to provide
external linkage for use by Python-internal code in different compilation
units? _Py_DecodeLocaleEx is called in Modules/_testcapimodule.c and also in
Objects/unicodeobject.c.
If we want to take steps to restrict symbol visibility, it will potentially
affect all of the code base - so presumably, a PEP would be required, even
though it's an implementation detail from the point of view of the language
itself?
Regards,
Vinay Sajip
_______________________________________________
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/H726K4PDW6PI34VVBX6HN26MAE5IZUNG/
