Re: [PATCH 10/11] Fix warnings in nedmalloc when compiling with GCC 4.4.0
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:46:53
Possibly related (same subject, not in this thread)
- 2016-06-15 · Re: [PATCH 10/11] Fix warnings in nedmalloc when compiling with GCC 4.4.0 · Junio C Hamano <hidden>
- 2016-06-15 · Re: [PATCH 10/11] Fix warnings in nedmalloc when compiling with GCC 4.4.0 · GeunSik Lim <hidden>
- 2016-06-15 · Re: [PATCH 10/11] Fix warnings in nedmalloc when compiling with GCC 4.4.0 · Johannes Schindelin <hidden>
- 2016-06-15 · Re: [PATCH 10/11] Fix warnings in nedmalloc when compiling with GCC 4.4.0 · Junio C Hamano <hidden>
- 2016-06-15 · Re: [PATCH 10/11] Fix warnings in nedmalloc when compiling with GCC 4.4.0 · Johannes Schindelin <hidden>
Steffen Prohaska [off-list ref] writes:
quoted hunk ↗ jump to hunk
@@ -2541,7 +2543,7 @@ struct malloc_params { static struct malloc_params mparams; /* Ensure mparams initialized */ -#define ensure_initialization() (mparams.magic != 0 || init_mparams()) +#define ensure_initialization() if (mparams.magic == 0) init_mparams() #if !ONLY_MSPACES
The code after the patch looks more fragile than the original. I know
there currently is no code like:
if (foo())
ensure_initialization();
else
warn("oops");
but this change still feels wrong.
What issue is this patch trying to work around? Returned value not being
used?
quoted hunk ↗ jump to hunk
diff --git a/compat/nedmalloc/nedmalloc.c b/compat/nedmalloc/nedmalloc.c index a381a7d..60a4093 100644 --- a/compat/nedmalloc/nedmalloc.c +++ b/compat/nedmalloc/nedmalloc.c@@ -34,7 +34,7 @@ DEALINGS IN THE SOFTWARE. /*#define FULLSANITYCHECKS*/ #include "nedmalloc.h" -#if defined(WIN32) && !defined(__MINGW32__) +#if defined(WIN32) #include <malloc.h> #endif
Can somebody enlighten me what this hunk is about, and how it helps GCC
4.4?
There are many "#if[n]def __MINGW32__" remaining in the codebase both
inside and outside compat/ area, so it is not that that symbol is somehow
special. I cannot even tell which one of the following is closer to the
reason behind this change:
(1) "Because tacking '&& !defined(__MINGW32__)' after defined(WIN32) is
unnecessary for such and such reasons, it is removed"; or
(2) "Because tacking '&& !defined(__MINGW32__)' after defined(WIN32) is
harmful for such and such reasons, it is removed".
Puzzled.