The problem with modifications to the contents of the glob/ subdirectory is that this code is extracted from the GNU libc project and included here, essentially verbatim.  I don't like to do too many changes here if possible, since it makes taking updates from GNU libc more difficult.

But we can certainly investigate the possibilities.

AFAIK, WINDOWS32 is used because the GNU Project doesn't like to be part of those who say that MS-Windows is ``a win''.  Therefore, we cannot remove WINDOWS32 and use _WIN32 instead.

As for its usage policy, WINDOWS32 should be used for OS- and runtime-dependent code, not for compiler-dependent code (so your assumption that it is for the MS compiler is incorrect).  The latter should use symbols specific to the offending compiler, such as _MINGW32_, __MSC_VER, etc.

That is the theory.  The practice could be different, so if you want to clean up the sources wrt this, I'm sure patches will be gladly accepted (although it's perhaps prudent to wait until the reorganization of the code is done).

As for Interix, I don't know how to handle that.  Ideally, it should not compile any of the WINDOWS32 code, since it is a Posix environment.  I think it's a bad design decision for it to define __MSC_VER, since that's the only universal symbol that can be used to distinguish the MS compiler from other Windows compilers.  (Such distinction is needed because the MS compiler has its own incompatible extensions and lacks some functionality, which makes it different from other Windows compilers.)  In the long run, the fact that __MSC_VER is defined in Interix will be a terrible nuisance for building portable software, because the absolute majority of packages out there assume that __MSC_VER is a Windows compiler.  But I'm not holding my breath for MS to stop defining __MSC_VER in Interix.

Finally, I'm not too happy to support your suggestion to replace WINDOWS32 by HAVE_ANSI_COMPILER in fnmatch, glob, and elsewhere.  The problems with _STDC_ are specific to the Microsoft Visual C, which defines _STDC_ to zero unless a special compiler switch is used to enforce strict ANSI build.  As long as WINDOWS32 stays in those #ifdef's, we will remember what is the offending compiler, but if we replace it with a much more anonymous HAVE_ANSI_COMPILER, we will forget the reason very soon, and will some day wonder why the condition is there at all (since any sane ANSI compiler always defines _STDC_ to a non-zero value).

Hi!

> I assume that WINDOWS32 is for MS compiler support - not for WIN32 specific
> code. I also see that changes have been made in the CVS source, at least in
> make.h - so take this for what it is.

WINDOWS32 is for win32 builds, be they compiled by gcc, MSVC or another compiler for the win32 platform.

> If I may suggest:
> Remove the WINDOWS32 conditional all together - it is not needed.
> For WIN32 specific parts there are already 2 constants defined:
> _WIN32 - internal constant defined for WIN32 binaries
> WIN32 - defined in the Windows SDK for the WIN32 API
> Both is defined and needed when compiling a WIN32 GNU make

Potentialy it could be replaced if there was one which would already be defined, depends if someone wants to go through the code and make that change really IMHO.