Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs

[Paul Eggert]

> From: Jim Meyering <address@hidden>
> Date: Mon, 09 Jun 2003 19:57:37 +0200

> One approach to eliminating *WIN* symbols from most of the source code
> would be to write an autoconf macro to test for the offending
> symbols and if they're found, then define some more palatable form,
> like WINDOWS32.

I like this idea.  Of the names mentioned by far, only W32, WOE32, and
WINDOWS32 are suitable.  The other names either use "win", which is
inappropriate cheerleading; or begin with underscore, which infringes
on the implementation space; or are confusingly obsolescent
(e.g. WINDOWSNT).  Personally I prefer Bruno's clever suggestion of
WOE32: it's short and mnemonic.  But WINDOWS32 would be OK too.

> But that'd mean every program that uses one of the affected .c or .h
> files would have to be sure to run the new corresponding autoconf macro.

True, but only if they want to be portable to Microsoft Windows; if
they don't invoke the macro, WINDOWS32 won't be defined and the code
will do the right thing on non-Microsoft-Windows platforms.

Surely this is a relatively minor problem.  The default state of
affairs is that a GNU program isn't portable to Microsoft Windows.
People who want to ensure portability to Microsoft Windows will have
to invoke that macro, but there are a zillion other things they have
to do too, and they have to be experts at this sort of thing -- and
also, if they're using gnulib code, the corresponding .m4 file will do
it for them automatically.

My own worry is that the maintenance burden will explode as people try
to port to various flavors of Microsoft Windows.  I prefer not to see
"#ifdef WOE32" in the code that I help maintain: it's distracting.
And if we have to distinguish between Windows 98 and Windows 2003 -- ouch!


"Eli Zaretskii" <address@hidden> writes:

> > From: Jim Meyering <address@hidden>
> > Date: Mon, 09 Jun 2003 08:31:53 +0200
> > 
> > Is there some symbol other than _WIN32 and __WIN32__ that is
> > consistently defined by compilers on those systems?
> 
> No, not to my knowledge.  These conditionals cover both MinGW and MSVC
> compilers (the former is a port of GCC and is free software, the
> latter is Microsoft's proprietary compiler), so something like _MSC
> (which is special to MSVC) or __GNUC__ alone could do.

__GNUC__ isn't right, since it's defined on other platforms.
gcc-3.3/gcc/config/i386/win32.h says that it always
defines either (__CYGWIN32__ and __CYGWIN__) or __MINGW32__,
so you could use "__CYGWIN32__ || __MINGW32__" if you wanted
to avoid _WIN32.

(Incidentally, "win32" is scattered all throughout the GCC sources;
see, for example, the file name mentioned above.)

However, isn't this point moot for strftime?  Jim Meyering has a
solution to test for the problem at configure-time, and Microsoft
Windows doesn't have the problem so it doesn't need to worry about it.