[PATCH][util/macros] xorg-macros.m4.in: use the autoconf cache for XORG_CHECK_MALLOC_ZERO

[Gaetan Nadon]

On 13-10-11 05:24 AM, Burton, Ross wrote:
> Hi,
>
> On 11 October 2013 02:23, Gaetan Nadon <memsize at videotron.ca> wrote:
>> If all modules expanding the macro are setting $enableval to auto, then
>> I think it works fine.
> The macro doesn't take arguments, so by definition all modules are
> using auto as the default unless the build system is explicitly
> passing --enable-malloc0returnsnull or --disable-malloc0returnsnull.
Correct.
>
>> Now suppose a next module is configured using
>> --disable-malloc0returnsnull, $enableval is now "no". The AC_LANG_PROGRAM
>> is not executed, the value of xorg_cv_malloc0_returns_null is not
>> changed (remains to the cached "yes" value), the value of
>> MALLOC_ZERO_RETURNS_NULL does not change (remains to "yes") and value of
>> *ZERO_CFLAGS do not change and are now wrong.
> No.
>
> If --disable is passed $enableval is "no" which is then assigned to
> MALLOC_ZERO_RETURNS_NULL in the AC_ARG_ENABLE block (as before), which
> results in the cache not being used and the test program not being ran
> (as before).
Correct, I had read it as being outside the block, my bad.
>> There are a number of permutations to check. Assuming the
>> AC_LANG_PROGRAM test always return the same value, it may be preceeded
>> by a module that was configured with enableval set to "yes" or "no".
> That's not a problem as far as the test is concerned.  The cache isn't
> written to by autoconf, only the user can do that.  If different
> modules are compiled with different values for this test then they'll
> "just" have different semantics for Xmalloc(0).
Ok.
>
>> I am also assuming that a module would not provide an alternate
>> implementation of malloc which would break my assumption above.
> Yes.  That's always been an assumption here and my test doesn't change
> it.  Note that this only impacts users of Xmalloc() which is reducing
> over time.
Ok.
>
>> I don't understand why someone would configure a module with --enable or
>> --disable. Can you make sense out of this?
> I'm not sure what you mean.  Personally I'd rip out the option
> entirely and rely on autodetection (for native builds) with autoconf
> site cache (for cross-compilation), but I left the patch in for
> minimal impact on other users.
I later found that, ironically, this option is intended for
cross-compiling. Because it is not possible to find out the behaviour of
malloc on the host system using a test, the builder has to inform  the
module using the --enable configure option.
>
> Ross
>
As it is, for the original version of the patch:

Reviewed-by: Gaetan Nadon <memsize at videotron.ca>