gh-93738: Documentation C syntax (Function glob patterns -> literal markup) (#97774)

5 files changed, 14 insertions, 14 deletions

diff --git a/Doc/c-api/arg.rst b/Doc/c-api/arg.rst
index c9dcf74..702c086 100644
--- a/Doc/c-api/arg.rst
+++ b/Doc/c-api/arg.rst
@@ -298,7 +298,7 @@ Other objects
       status = converter(object, address);
 
    where *object* is the Python object to be converted and *address* is the
-   :c:type:`void*` argument that was passed to the :c:func:`PyArg_Parse\*` function.
+   :c:type:`void*` argument that was passed to the ``PyArg_Parse*`` function.
    The returned *status* should be ``1`` for a successful conversion and ``0`` if
    the conversion has failed.  When the conversion fails, the *converter* function
    should raise an exception and leave the content of *address* unmodified.
@@ -372,9 +372,9 @@ what is specified for the corresponding format unit in that case.
 
 For the conversion to succeed, the *arg* object must match the format
 and the format must be exhausted.  On success, the
-:c:func:`PyArg_Parse\*` functions return true, otherwise they return
+``PyArg_Parse*`` functions return true, otherwise they return
 false and raise an appropriate exception. When the
-:c:func:`PyArg_Parse\*` functions fail due to conversion failure in one
+``PyArg_Parse*`` functions fail due to conversion failure in one
 of the format units, the variables at the addresses corresponding to that
 and the following format units are left untouched.
 
@@ -481,7 +481,7 @@ Building values
 .. c:function:: PyObject* Py_BuildValue(const char *format, ...)
 
    Create a new value based on a format string similar to those accepted by the
-   :c:func:`PyArg_Parse\*` family of functions and a sequence of values.  Returns
+   ``PyArg_Parse*`` family of functions and a sequence of values.  Returns
    the value or ``NULL`` in the case of an error; an exception will be raised if
    ``NULL`` is returned.
 
diff --git a/Doc/c-api/exceptions.rst b/Doc/c-api/exceptions.rst
index 7221957..087e0a6 100644
--- a/Doc/c-api/exceptions.rst
+++ b/Doc/c-api/exceptions.rst
@@ -14,7 +14,7 @@ there is a global indicator (per thread) of the last error that occurred.  Most
 C API functions don't clear this on success, but will set it to indicate the
 cause of the error on failure.  Most C API functions also return an error
 indicator, usually ``NULL`` if they are supposed to return a pointer, or ``-1``
-if they return an integer (exception: the :c:func:`PyArg_\*` functions
+if they return an integer (exception: the ``PyArg_*`` functions
 return ``1`` for success and ``0`` for failure).
 
 Concretely, the error indicator consists of three object pointers: the
@@ -370,7 +370,7 @@ Querying the error indicator
 .. c:function:: PyObject* PyErr_Occurred()
 
    Test whether the error indicator is set.  If set, return the exception *type*
-   (the first argument to the last call to one of the :c:func:`PyErr_Set\*`
+   (the first argument to the last call to one of the ``PyErr_Set*``
    functions or to :c:func:`PyErr_Restore`).  If not set, return ``NULL``.  You do not
    own a reference to the return value, so you do not need to :c:func:`Py_DECREF`
    it.
diff --git a/Doc/c-api/init.rst b/Doc/c-api/init.rst
index cb3bfed..efa5838 100644
--- a/Doc/c-api/init.rst
+++ b/Doc/c-api/init.rst
@@ -956,11 +956,11 @@ from a C thread is::
    /* Release the thread. No Python API allowed beyond this point. */
    PyGILState_Release(gstate);
 
-Note that the :c:func:`PyGILState_\*` functions assume there is only one global
+Note that the ``PyGILState_*`` functions assume there is only one global
 interpreter (created automatically by :c:func:`Py_Initialize`).  Python
 supports the creation of additional interpreters (using
 :c:func:`Py_NewInterpreter`), but mixing multiple interpreters and the
-:c:func:`PyGILState_\*` API is unsupported.
+``PyGILState_*`` API is unsupported.
 
 
 .. _fork-and-threads:
@@ -1587,7 +1587,7 @@ operations executed by such objects may affect the wrong (sub-)interpreter's
 dictionary of loaded modules. It is equally important to avoid sharing
 objects from which the above are reachable.
 
-Also note that combining this functionality with :c:func:`PyGILState_\*` APIs
+Also note that combining this functionality with ``PyGILState_*`` APIs
 is delicate, because these APIs assume a bijection between Python thread states
 and OS-level threads, an assumption broken by the presence of sub-interpreters.
 It is highly recommended that you don't switch sub-interpreters between a pair
diff --git a/Doc/c-api/module.rst b/Doc/c-api/module.rst
index 94c8d9f..e2ba157 100644
--- a/Doc/c-api/module.rst
+++ b/Doc/c-api/module.rst
@@ -64,8 +64,8 @@ Module Objects
    If *module* is not a module object (or a subtype of a module object),
    :exc:`SystemError` is raised and ``NULL`` is returned.
 
-   It is recommended extensions use other :c:func:`PyModule_\*` and
-   :c:func:`PyObject_\*` functions rather than directly manipulate a module's
+   It is recommended extensions use other ``PyModule_*`` and
+   ``PyObject_*`` functions rather than directly manipulate a module's
    :attr:`~object.__dict__`.
 
 
diff --git a/Doc/c-api/typeobj.rst b/Doc/c-api/typeobj.rst
index 86c0830..8ccdece 100644
--- a/Doc/c-api/typeobj.rst
+++ b/Doc/c-api/typeobj.rst
@@ -7,8 +7,8 @@ Type Objects
 
 Perhaps one of the most important structures of the Python object system is the
 structure that defines a new type: the :c:type:`PyTypeObject` structure.  Type
-objects can be handled using any of the :c:func:`PyObject_\*` or
-:c:func:`PyType_\*` functions, but do not offer much that's interesting to most
+objects can be handled using any of the ``PyObject_*`` or
+``PyType_*`` functions, but do not offer much that's interesting to most
 Python applications. These objects are fundamental to how objects behave, so
 they are very important to the interpreter itself and to any extension module
 that implements new types.
@@ -1519,7 +1519,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
    If the instances of this type are weakly referenceable, this field is greater
    than zero and contains the offset in the instance structure of the weak
    reference list head (ignoring the GC header, if present); this offset is used by
-   :c:func:`PyObject_ClearWeakRefs` and the :c:func:`PyWeakref_\*` functions.  The
+   :c:func:`PyObject_ClearWeakRefs` and the ``PyWeakref_*`` functions.  The
    instance structure needs to include a field of type :c:expr:`PyObject*` which is
    initialized to ``NULL``.