Rename zero_realloc option "strict" to "alloc".

With realloc(ptr, 0) being UB per C23, the option name "strict" makes less sense
now.  Rename to "alloc" which describes the behavior.

7 files changed, 16 insertions, 16 deletions

diff --git a/Makefile.in b/Makefile.in
index cf6d5687..1193cd85 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -289,7 +289,7 @@ TESTS_UNIT := \
 	$(srcroot)test/unit/zero.c \
 	$(srcroot)test/unit/zero_realloc_abort.c \
 	$(srcroot)test/unit/zero_realloc_free.c \
-	$(srcroot)test/unit/zero_realloc_strict.c \
+	$(srcroot)test/unit/zero_realloc_alloc.c \
 	$(srcroot)test/unit/zero_reallocs.c
 ifeq (@enable_prof@, 1)
 TESTS_UNIT += \
diff --git a/doc/jemalloc.xml.in b/doc/jemalloc.xml.in
index 6e2099ad..8c3703bd 100644
--- a/doc/jemalloc.xml.in
+++ b/doc/jemalloc.xml.in
@@ -1580,19 +1580,19 @@ malloc_conf = "xmalloc:true";]]></programlisting>
         </term>
         <listitem><para> Determines the behavior of
 	<function>realloc()</function> when passed a value of zero for the new
-	size.  <quote>strict</quote> treats this as an allocation of size zero
+	size.  <quote>alloc</quote> treats this as an allocation of size zero
 	(and returns a non-null result except in case of resource exhaustion).
 	<quote>free</quote> treats this as a deallocation of the pointer, and
 	returns <constant>NULL</constant> without setting
 	<varname>errno</varname>.  <quote>abort</quote> aborts the process if
-	zero is passed.  The default is <quote>strict</quote>.</para>
+	zero is passed.  The default is <quote>alloc</quote>.</para>
 
 	<para>There is considerable divergence of behaviors across
 	implementations in handling this case. Many have the behavior of
 	<quote>free</quote>. This can introduce security vulnerabilities, since
 	a <constant>NULL</constant> return value indicates failure, and the
 	continued validity of the passed-in pointer (per POSIX and C11).
-	<quote>strict</quote> is safe, but can cause leaks in programs that
+	<quote>alloc</quote> is safe, but can cause leaks in programs that
 	expect the common behavior.  Programs intended to be portable and
 	leak-free cannot assume either behavior, and must therefore never call
 	realloc with a size of 0.  The <quote>abort</quote> option enables these
diff --git a/include/jemalloc/internal/jemalloc_internal_types.h b/include/jemalloc/internal/jemalloc_internal_types.h
index 61c1f31a..62c2b59c 100644
--- a/include/jemalloc/internal/jemalloc_internal_types.h
+++ b/include/jemalloc/internal/jemalloc_internal_types.h
@@ -9,7 +9,7 @@ typedef int malloc_cpuid_t;
 /* When realloc(non-null-ptr, 0) is called, what happens? */
 enum zero_realloc_action_e {
 	/* Realloc(ptr, 0) is free(ptr); return malloc(0); */
-	zero_realloc_action_strict = 0,
+	zero_realloc_action_alloc = 0,
 	/* Realloc(ptr, 0) is free(ptr); */
 	zero_realloc_action_free = 1,
 	/* Realloc(ptr, 0) aborts. */
diff --git a/src/jemalloc.c b/src/jemalloc.c
index 364dc57f..7e5bd338 100644
--- a/src/jemalloc.c
+++ b/src/jemalloc.c
@@ -112,12 +112,12 @@ bool opt_cache_oblivious =
     ;
 
 zero_realloc_action_t opt_zero_realloc_action =
-    zero_realloc_action_strict;
+    zero_realloc_action_alloc;
 
 atomic_zu_t zero_realloc_count = ATOMIC_INIT(0);
 
 const char *zero_realloc_mode_names[] = {
-	"strict",
+	"alloc",
 	"free",
 	"abort",
 };
@@ -1649,9 +1649,9 @@ malloc_conf_init_helper(sc_data_t *sc_data, unsigned bin_shard_sizes[SC_NBINS],
 				CONF_CONTINUE;
 			}
 			if (CONF_MATCH("zero_realloc")) {
-				if (CONF_MATCH_VALUE("strict")) {
+				if (CONF_MATCH_VALUE("alloc")) {
 					opt_zero_realloc_action
-					    = zero_realloc_action_strict;
+					    = zero_realloc_action_alloc;
 				} else if (CONF_MATCH_VALUE("free")) {
 					opt_zero_realloc_action
 					    = zero_realloc_action_free;
@@ -3578,9 +3578,9 @@ do_realloc_nonnull_zero(void *ptr) {
 	if (config_stats) {
 		atomic_fetch_add_zu(&zero_realloc_count, 1, ATOMIC_RELAXED);
 	}
-	if (opt_zero_realloc_action == zero_realloc_action_strict) {
+	if (opt_zero_realloc_action == zero_realloc_action_alloc) {
 		/*
-		 * The user might have gotten a strict setting while expecting a
+		 * The user might have gotten an alloc setting while expecting a
 		 * free setting.  If that's the case, we at least try to
 		 * reduce the harm, and turn off the tcache while allocating, so
 		 * that we'll get a true first fit.
diff --git a/test/unit/zero_realloc_strict.c b/test/unit/zero_realloc_alloc.c
index 249d838a..65e07bdb 100644
--- a/test/unit/zero_realloc_strict.c
+++ b/test/unit/zero_realloc_alloc.c
@@ -24,7 +24,7 @@ deallocated() {
 	return deallocated;
 }
 
-TEST_BEGIN(test_realloc_strict) {
+TEST_BEGIN(test_realloc_alloc) {
 	void *ptr = mallocx(1, 0);
 	expect_ptr_not_null(ptr, "Unexpected mallocx error");
 	uint64_t allocated_before = allocated();
@@ -44,5 +44,5 @@ TEST_END
 int
 main(void) {
 	return test(
-	    test_realloc_strict);
+	    test_realloc_alloc);
 }
diff --git a/test/unit/zero_realloc_alloc.sh b/test/unit/zero_realloc_alloc.sh
new file mode 100644
index 00000000..802687cf
--- /dev/null
+++ b/test/unit/zero_realloc_alloc.sh
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+export MALLOC_CONF="zero_realloc:alloc"
diff --git a/test/unit/zero_realloc_strict.sh b/test/unit/zero_realloc_strict.sh
deleted file mode 100644
index 314dcd0a..00000000
--- a/test/unit/zero_realloc_strict.sh
+++ /dev/null
@@ -1,3 +0,0 @@
-#!/bin/sh
-
-export MALLOC_CONF="zero_realloc:strict"