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? -- 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