On Tue, Dec 03, 2013 at 08:55:17PM -0700, Eric Blake wrote: > MALLOC_CHECK_ in the environment at the start of ./configure affects > hundreds or even thousands of processes. mallopt() within a single > conftest affects only the one process. I found it slightly easier to > use mallopt() within the conftest code than to figure out how to ensure > I was injecting MALLOC_CHECK_ into the environment of the m4 code that > runs the conftest program without also leaking into the environment of > the rest of the configure script.
OK, thanks for explaining your use case. > > However, it looks like we don't do __malloc_check_init > > for M_CHECK_ACTION, which is what initializes the additional checks. > > Does anyone know if it is intentional? It looks like a bug to me. > > That's more a matter for glibc to decide; for now, all I was worried > about was patching gnulib in a manner that would prevent configure from Right, that question was in fact pointed at glibc maintainers. Siddhesh
