On 13-10-11 05:24 AM, Burton, Ross wrote: > Hi, > > On 11 October 2013 02:23, Gaetan Nadon <[email protected]> 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 <[email protected]> _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
