followup to AC_FUNC_MALLOC, AC_FUNC_REALLOC changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Paul,

1) The AC_FUNC_MALLOC, AC_FUNC_REALLOC changes have the effect that code
that does

  test $ac_cv_func_malloc_0_nonnull = no

or

  test $ac_cv_func_realloc_0_nonnull = no

may now produce an error message in the log (because these values may
now consist of two words). This is worth mentioning in the doc (maybe
even in the NEWS file?).

Proposed patch: doc-tweak.diff (attached)

2) The only platform that does not set errno when malloc() fails is
native Windows. There are two possible runtime libraries on native Windows:
MSVCRT and UCRT. UCRT is the successor of MSVCRT, and it has a malloc()
that sets errno since MSVC 14 (Visual Studio 2015). The MSVCRT, which is
still used by mingw, also changed its behaviour accordingly, no later
than 2019. So, on modern Windows systems, malloc() sets errno.

Proposed patch: malloc.diff (attached)

Bruno
doc: Document that $ac_cv_func_{m,re}alloc_0_nonnull may contain spaces.

* doc/autoconf.texi (Particular Functions): Document that the value of the
cache variables of AC_FUNC_MALLOC and AC_FUNC_REALLOC may contain a space.

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 1ff2f47d..e71782cc 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -5390,6 +5390,8 @@ rpl_malloc (size_t n)
 
 The result of this macro is cached in the
 @code{ac_cv_func_malloc_0_nonnull} variable.
+Note that the value of this variable may contain a space:
+@code{yes}, @code{no}, @code{guessing yes}, or @code{guessing no}.
 
 If you don't want to maintain a @code{malloc.c} file in your package
 manually, you can instead use the Gnulib module @code{malloc-gnu}.
@@ -5497,6 +5499,8 @@ the native @code{realloc} is not used in the main project.  See
 
 The result of this macro is cached in the
 @code{ac_cv_func_realloc_0_nonnull} variable.
+Note that the value of this variable may contain a space:
+@code{yes}, @code{no}, @code{guessing yes}, or @code{guessing no}.
 
 This macro does not check compatibility with glibc @code{realloc (@var{p}, 0)}
 when @var{p} is non-null, as glibc 1--2.1 behaves differently from glibc
AC_FUNC_MALLOC now guesses yes when cross-compiling.

Rationale: The only platform that had this problem was native Windows,
and MSVC's malloc sets errno since 2015 at least.

* lib/autoconf/functions.m4 (AC_FUNC_MALLOC): Guess yes when cross-compiling.

diff --git a/lib/autoconf/functions.m4 b/lib/autoconf/functions.m4
index 23a0bf8a..c12e1987 100644
--- a/lib/autoconf/functions.m4
+++ b/lib/autoconf/functions.m4
@@ -1020,7 +1020,7 @@ AC_DEFUN([AC_FUNC_MALLOC],
    AC_LIBOBJ(malloc)
    AC_DEFINE([malloc], [rpl_malloc],
       [Define to rpl_malloc if the replacement function should be used.])],
-  ["guessing no"])
+  ["guessing yes"])
 ])# AC_FUNC_MALLOC
 
 

[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux