On Wed, May 25, 2011 at 8:30 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > mduft@xxxxxxxxxx writes: > >> At least on Interix, NULL is defined in unistd.h, and not including it >> causes compilation failure. >> >> Signed-off-by: Markus Duft <mduft@xxxxxxxxxx> >> --- >> compat/fnmatch/fnmatch.c | 1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> diff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c >> index 14feac7..0238cca 100644 >> --- a/compat/fnmatch/fnmatch.c >> +++ b/compat/fnmatch/fnmatch.c >> @@ -25,6 +25,7 @@ >> # define _GNU_SOURCE 1 >> #endif >> >> +#include <unistd.h> >> #include <errno.h> >> #include <fnmatch.h> >> #include <ctype.h> > > The header stddef.h is where NULL is supposed to be defined, and commonly > used headers are supposed to define NULL the same way as stddef.h does. > There is a conditional inclusion of stdlib.h in fnmatch.c and stdlib.h is > one of those files; probably that is how the upstream pulls in NULL when > compiling this. > > But we don't define STDC_HEADERS nor _LIBC (and we shouldn't), so I don't > know how the existing users of compat/fnmatch/ gets the defintion of NULL > from. Output from "gcc -E -dD -DNO_FNMATCH compat/fnmatch/fnmatch.c" does > not seem to show any NULL defined. > > Other platforms (e.g. SunOS, IRIX, HPUX, Windows) use NO_FNMATCH_CASEFOLD > and compile this file. How are they getting their NULLs? Windows/MinGW: $ gcc -E -dD -DNO_FNMATCH compat/fnmatch/fnmatch.c | grep NULL compat/fnmatch/fnmatch.c:29:21: error: fnmatch.h: No such file or directory #define __MINGW_ATTRIB_NONNULL(arg) __attribute__ ((__nonnull__ (arg))) #undef __need_NULL #define __need_NULL #undef NULL #define NULL ((void *)0) #undef __need_NULL The "#define NULL ((void *)0)"-line comes from stddef.h, which is included from string.h, which in turn is included by fnmatch.c. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html