PEP 670: Nitpick (#2116)
This commit is contained in:
parent
f991f604b6
commit
c3ddc82c51
45
pep-0670.rst
45
pep-0670.rst
|
@ -17,7 +17,7 @@ Convert macros to static inline functions or regular functions.
|
|||
Remove the return value of macros having a return value, whereas they
|
||||
should not, to detect bugs in C extensions when the C API is misused.
|
||||
|
||||
Some function arguments are still casted to ``PyObject*`` to prevent
|
||||
Some function arguments are still cast to ``PyObject*`` to prevent
|
||||
emitting new compiler warnings.
|
||||
|
||||
|
||||
|
@ -25,8 +25,8 @@ Rationale
|
|||
=========
|
||||
|
||||
The use of macros may have unintended adverse effects that are hard to
|
||||
avoid, even for the experienced C developers. Some issues have been
|
||||
known for years, while others have been discovered recently in Python.
|
||||
avoid, even for experienced C developers. Some issues have been known for
|
||||
years, while others have been discovered recently in Python.
|
||||
Working around macro pitfalls makes the macro coder harder to read and
|
||||
to maintain.
|
||||
|
||||
|
@ -55,21 +55,21 @@ The `GCC documentation
|
|||
<https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html>`_ lists several
|
||||
common macro pitfalls:
|
||||
|
||||
- Misnesting;
|
||||
- Operator precedence problems;
|
||||
- Swallowing the semicolon;
|
||||
- Duplication of side effects;
|
||||
- Self-referential macros;
|
||||
- Argument prescan;
|
||||
- Newlines in arguments.
|
||||
- Misnesting
|
||||
- Operator precedence problems
|
||||
- Swallowing the semicolon
|
||||
- Duplication of side effects
|
||||
- Self-referential macros
|
||||
- Argument prescan
|
||||
- Newlines in arguments
|
||||
|
||||
|
||||
Performance and inlining
|
||||
========================
|
||||
|
||||
Static inline functions is a feature added to the C99 standard. In 2021,
|
||||
C compilers can inline them and have efficient heuristics to decide if a
|
||||
function should be inlined or not.
|
||||
Static inline functions is a feature added to the C99 standard. Modern
|
||||
C compilers have efficient heuristics to decide if a function should be inlined
|
||||
or not.
|
||||
|
||||
When a C compiler decides to not inline, there is likely a good reason.
|
||||
For example, inlining would reuse a register which require to
|
||||
|
@ -90,9 +90,7 @@ decide if function should be inlined or not.
|
|||
Force inlining
|
||||
--------------
|
||||
|
||||
If a developer is convinced to know better machine code than C compiler,
|
||||
which is very unlikely, it is still possible to mark the function with
|
||||
the ``Py_ALWAYS_INLINE`` macro. This macro uses
|
||||
The ``Py_ALWAYS_INLINE`` macro can be used to force inlining. This macro uses
|
||||
``__attribute__((always_inline))`` with GCC and Clang, and
|
||||
``__forceinline`` with MSC.
|
||||
|
||||
|
@ -165,8 +163,7 @@ functions.
|
|||
|
||||
The performance impact of such conversion should be measured with
|
||||
benchmarks. If there is a significant slowdown, there should be a good
|
||||
reason to do the conversion. One reason can be hiding some
|
||||
implementation details.
|
||||
reason to do the conversion. One reason can be hiding implementation details.
|
||||
|
||||
Using static inline functions in the internal C API is fine: the
|
||||
internal C API exposes implemenation details by design and should not be
|
||||
|
@ -194,8 +191,8 @@ For example, the ``Py_TYPE(obj)`` macro casts its ``obj`` argument to
|
|||
The undocumented private ``_Py_TYPE()`` function must not be called
|
||||
directly. Only the documented public ``Py_TYPE()`` macro must be used.
|
||||
|
||||
Later, the cast can be removed on a case by case basis, but it is out of
|
||||
this PEP scope.
|
||||
Later, the cast can be removed on a case by case basis, but that is out of
|
||||
scope for this PEP.
|
||||
|
||||
Remove the return value
|
||||
-----------------------
|
||||
|
@ -205,10 +202,10 @@ value. In some cases, the macro must not have a return value and can be
|
|||
misused in third party C extensions. See `bpo-30459
|
||||
<https://bugs.python.org/issue30459>`_ for the example of
|
||||
``PyList_SET_ITEM()`` and ``PyCell_SET()`` macros. It is not easy to
|
||||
notice this issue while reviewing a macro code.
|
||||
notice this issue while reviewing macro code.
|
||||
|
||||
These macros are converted to functions using the ``void`` return type
|
||||
to remove their return value. Removing the return value detects bugs in
|
||||
to remove their return value. Removing the return value aids detecting bugs in
|
||||
C extensions when the C API is misused.
|
||||
|
||||
|
||||
|
@ -238,8 +235,8 @@ the macro.
|
|||
People using macros should be considered "consenting adults". People who
|
||||
feel unsafe with macros should simply not use them.
|
||||
|
||||
Example of hard to read macros
|
||||
==============================
|
||||
Examples of hard to read macros
|
||||
===============================
|
||||
|
||||
_Py_NewReference()
|
||||
------------------
|
||||
|
|
Loading…
Reference in New Issue