Issue #5319: New Py_FinalizeEx() API to exit with status 120 on failure

1 files changed, 4 insertions, 4 deletions

diff --git a/Misc/SpecialBuilds.txt b/Misc/SpecialBuilds.txt
index 3004174..4b673fd 100644
--- a/Misc/SpecialBuilds.txt
+++ b/Misc/SpecialBuilds.txt
@@ -65,9 +65,9 @@ sys.getobjects(max[, type])
     simply by virtue of being in the list.
 
 envvar PYTHONDUMPREFS
-    If this envvar exists, Py_Finalize() arranges to print a list of all
+    If this envvar exists, Py_FinalizeEx() arranges to print a list of all
     still-live heap objects.  This is printed twice, in different formats,
-    before and after Py_Finalize has cleaned up everything it can clean up.  The
+    before and after Py_FinalizeEx has cleaned up everything it can clean up.  The
     first output block produces the repr() of each object so is more
     informative; however, a lot of stuff destined to die is still alive then.
     The second output block is much harder to work with (repr() can't be invoked
@@ -144,7 +144,7 @@ Special gimmicks:
 
 envvar PYTHONMALLOCSTATS
     If this envvar exists, a report of pymalloc summary statistics is printed to
-    stderr whenever a new arena is allocated, and also by Py_Finalize().
+    stderr whenever a new arena is allocated, and also by Py_FinalizeEx().
 
 Changed in 2.5:  The number of extra bytes allocated is 4*sizeof(size_t).
 Before it was 16 on all boxes, reflecting that Python couldn't make use of
@@ -179,7 +179,7 @@ Each type object grows three new members:
      */
     int tp_maxalloc;
 
-Allocation and deallocation code keeps these counts up to date.  Py_Finalize()
+Allocation and deallocation code keeps these counts up to date.  Py_FinalizeEx()
 displays a summary of the info returned by sys.getcounts() (see below), along
 with assorted other special allocation counts (like the number of tuple
 allocations satisfied by a tuple free-list, the number of 1-character strings