[bug #16476] Inconsistent function macros - again

[Eli Zaretskii]

Follow-up Comment #3, bug #16476 (project make):

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).


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=16476>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/