Derek Price <[EMAIL PROTECTED]> writes: > I chose the _SYS_CDEFS_H route since it seemed simplest to me, though I > chose to name the macro `MISSING_SYS_CDEFS_H'.
Sorry, that's not right, since it fails in the following scenario: #define MISSING_SYS_CDEFS_H 27 #include <glob.h> in an ordinary program that is not using gnulib, but is using glibc. MISSING_SYS_CDEFS_H is part of the user's namespace, and should not affect how <glob.h> works. Let's just use _SYS_CDEFS_H. We can then remove all mention of MISSING_SYS_CDEFS_H from glob_.h and undo the most recent change to glob.m4. This should be OK: if we run into some non-glibc that has this problem it will probably use some other include file anyway. > You told me it was safe to make this assumption originally. Sorry, I hadn't thought through the implications of merging this back into glibc. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
