Tor Arntsen <tor@xxxxxxxxxxx> writes:
> On Wed, May 25, 2011 at 20:30, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> ...
>> 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.
>
> According to POSIX (well, IEEE Std 1003.1, 2004 Edition at least)
> unistd.h must define NULL:
Yes, unistd.h is also one of the common header files just like stdlib.h and
stdio.h that are required to define NULL the same way as stddef.h does.
Cf.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html
>> Other platforms (e.g. SunOS, IRIX, HPUX, Windows) use NO_FNMATCH_CASEFOLD
>> and compile this file. ÂHow are they getting their NULLs?
>
> IRIX defines NULL in ...
> ... presumably it's in some compiler-provided place.
Yes, but that still does not explain where compat/fnmatch/fnmatch.c gets
its NULL from.
> #ifndef NULL
> #define NULL 0 /* or sometimes 0L */
> #endif
You probably would want to say "(void *) 0" if you quote POSIX in the same
message ;-).
Cf.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stddef.h.html
To recap my original question that is not unanswered, the current codebase
does not include unistd.h nor stddef.h when compiling the compatibility
fnmatch.c source we borrowed from glibc, but nobody seems to have
complained that it does not compile due to the lack of NULL, so they must
be getting their NULL from somewhere already, but I couldn't find where.
That is what I was wondering.
--
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