-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
bpo-11410: Standardize and use symbol visibility attributes across POSIX and Windows. #16347
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
Changes from 5 commits
cbdada0
50c661c
6421318
049cd45
dc85dbb
f4a3429
886a68e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
#ifndef Py_EXPORTS_H | ||
#define Py_EXPORTS_H | ||
|
||
#if defined(_WIN32) || defined(__CYGWIN__) | ||
#define Py_IMPORTED_SYMBOL __declspec(dllimport) | ||
#define Py_EXPORTED_SYMBOL __declspec(dllexport) | ||
#define Py_LOCAL_SYMBOL | ||
#else | ||
#if __GNUC__ >= 4 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. clang also supports this attribute. Using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Some versions of e.g. Ubuntu and CentOS are still on GCC 4.8. I'll try to generalise it. |
||
#define Py_IMPORTED_SYMBOL __attribute__ ((visibility ("default"))) | ||
#define Py_EXPORTED_SYMBOL __attribute__ ((visibility ("default"))) | ||
#define Py_LOCAL_SYMBOL __attribute__ ((visibility ("hidden"))) | ||
#else | ||
#define Py_IMPORTED_SYMBOL | ||
#define Py_EXPORTED_SYMBOL | ||
#define Py_LOCAL_SYMBOL | ||
#endif | ||
#endif | ||
|
||
#endif /* Py_EXPORTS_H */ |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
Better control over symbol visibility is provided through use of the | ||
visibility attributes available in gcc >= 4.0, provided in a uniform way | ||
across POSIX and Windows. The POSIX build files have been updated to compile | ||
with -fvisibility=hidden, minimising exported symbols. |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,6 +2,8 @@ | |
* Declarations shared between the different parts of the io module | ||
*/ | ||
|
||
#include "exports.h" | ||
|
||
/* ABCs */ | ||
extern PyTypeObject PyIOBase_Type; | ||
extern PyTypeObject PyRawIOBase_Type; | ||
|
@@ -183,4 +185,4 @@ extern PyObject *_PyIO_str_write; | |
extern PyObject *_PyIO_empty_str; | ||
extern PyObject *_PyIO_empty_bytes; | ||
|
||
extern PyTypeObject _PyBytesIOBuffer_Type; | ||
extern Py_EXPORTED_SYMBOL PyTypeObject _PyBytesIOBuffer_Type; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why do you export these _io types, they should be private, no? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Even if I remove
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -106,7 +106,7 @@ PyArg_Parse(PyObject *args, const char *format, ...) | |
return retval; | ||
} | ||
|
||
int | ||
PyAPI_FUNC(int) | ||
_PyArg_Parse_SizeT(PyObject *args, const char *format, ...) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why do we have to export _PyArg symbols in specific? Can't we only configure the visibility in header files? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The problem here is that these aren't declared in any header file - there are forward declarations at the top of To add to the fun,
if |
||
{ | ||
int retval; | ||
|
@@ -131,7 +131,7 @@ PyArg_ParseTuple(PyObject *args, const char *format, ...) | |
return retval; | ||
} | ||
|
||
int | ||
PyAPI_FUNC(int) | ||
_PyArg_ParseTuple_SizeT(PyObject *args, const char *format, ...) | ||
{ | ||
int retval; | ||
|
@@ -156,7 +156,7 @@ _PyArg_ParseStack(PyObject *const *args, Py_ssize_t nargs, const char *format, . | |
return retval; | ||
} | ||
|
||
int | ||
PyAPI_FUNC(int) | ||
_PyArg_ParseStack_SizeT(PyObject *const *args, Py_ssize_t nargs, const char *format, ...) | ||
{ | ||
int retval; | ||
|
@@ -182,7 +182,7 @@ PyArg_VaParse(PyObject *args, const char *format, va_list va) | |
return retval; | ||
} | ||
|
||
int | ||
PyAPI_FUNC(int) | ||
_PyArg_VaParse_SizeT(PyObject *args, const char *format, va_list va) | ||
{ | ||
va_list lva; | ||
|
@@ -1442,7 +1442,7 @@ PyArg_ParseTupleAndKeywords(PyObject *args, | |
return retval; | ||
} | ||
|
||
int | ||
PyAPI_FUNC(int) | ||
_PyArg_ParseTupleAndKeywords_SizeT(PyObject *args, | ||
PyObject *keywords, | ||
const char *format, | ||
|
@@ -1493,7 +1493,7 @@ PyArg_VaParseTupleAndKeywords(PyObject *args, | |
return retval; | ||
} | ||
|
||
int | ||
PyAPI_FUNC(int) | ||
_PyArg_VaParseTupleAndKeywords_SizeT(PyObject *args, | ||
PyObject *keywords, | ||
const char *format, | ||
|
@@ -1519,7 +1519,7 @@ _PyArg_VaParseTupleAndKeywords_SizeT(PyObject *args, | |
return retval; | ||
} | ||
|
||
int | ||
PyAPI_FUNC(int) | ||
_PyArg_ParseTupleAndKeywordsFast(PyObject *args, PyObject *keywords, | ||
struct _PyArg_Parser *parser, ...) | ||
{ | ||
|
@@ -1532,7 +1532,7 @@ _PyArg_ParseTupleAndKeywordsFast(PyObject *args, PyObject *keywords, | |
return retval; | ||
} | ||
|
||
int | ||
PyAPI_FUNC(int) | ||
_PyArg_ParseTupleAndKeywordsFast_SizeT(PyObject *args, PyObject *keywords, | ||
struct _PyArg_Parser *parser, ...) | ||
{ | ||
|
@@ -1545,7 +1545,7 @@ _PyArg_ParseTupleAndKeywordsFast_SizeT(PyObject *args, PyObject *keywords, | |
return retval; | ||
} | ||
|
||
int | ||
PyAPI_FUNC(int) | ||
_PyArg_ParseStackAndKeywords(PyObject *const *args, Py_ssize_t nargs, PyObject *kwnames, | ||
struct _PyArg_Parser *parser, ...) | ||
{ | ||
|
@@ -1558,7 +1558,7 @@ _PyArg_ParseStackAndKeywords(PyObject *const *args, Py_ssize_t nargs, PyObject * | |
return retval; | ||
} | ||
|
||
int | ||
PyAPI_FUNC(int) | ||
_PyArg_ParseStackAndKeywords_SizeT(PyObject *const *args, Py_ssize_t nargs, PyObject *kwnames, | ||
struct _PyArg_Parser *parser, ...) | ||
{ | ||
|
@@ -1572,7 +1572,7 @@ _PyArg_ParseStackAndKeywords_SizeT(PyObject *const *args, Py_ssize_t nargs, PyOb | |
} | ||
|
||
|
||
int | ||
PyAPI_FUNC(int) | ||
_PyArg_VaParseTupleAndKeywordsFast(PyObject *args, PyObject *keywords, | ||
struct _PyArg_Parser *parser, va_list va) | ||
{ | ||
|
@@ -1586,7 +1586,7 @@ _PyArg_VaParseTupleAndKeywordsFast(PyObject *args, PyObject *keywords, | |
return retval; | ||
} | ||
|
||
int | ||
PyAPI_FUNC(int) | ||
_PyArg_VaParseTupleAndKeywordsFast_SizeT(PyObject *args, PyObject *keywords, | ||
struct _PyArg_Parser *parser, va_list va) | ||
{ | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,8 @@ | ||
/* Generated by Parser/pgen */ | ||
|
||
#include "exports.h" | ||
#include "grammar.h" | ||
grammar _PyParser_Grammar; | ||
Py_EXPORTED_SYMBOL grammar _PyParser_Grammar; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would prefer to not export private symbols (names starting with "_Py"). Or is there a good reason to export that one? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If you don't export it, e.g. by using just plain
|
||
static const arc arcs_0_0[3] = { | ||
{2, 1}, | ||
{3, 2}, | ||
|
@@ -2693,7 +2694,7 @@ static const label labels[183] = { | |
{346, 0}, | ||
{347, 0}, | ||
}; | ||
grammar _PyParser_Grammar = { | ||
Py_EXPORTED_SYMBOL grammar _PyParser_Grammar = { | ||
92, | ||
dfas, | ||
{183, labels}, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer to restrict the number of header files: why not reusing pyport.h?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because exporting symbols is orthogonal to other things. Consider
graminit.c
- it's a very low-level module which needs to export a symbol, but doesn't really use any other Python-specific or system-specific stuff. If you replace "exports.h" with "pyport.h" ingraminit.c
, you get an error when compiling:Including
<stddef.h>
before"pyport.h"
doesn't fix things:So you end up having to include
"Python.h"
instead, which appears to be overkill as it exposes a lot of things to code ingraminit.c
which aren't needed by that code.