Sat 27 Apr 2013 05:45:12 PM UTC, comment #6:
I'm closing this bug because too much time has passed, and the code in question has likely changed beyond recognition. So have the MS compilers and environments.
If this problem is still relevant, please reopen with the current state of affairs, and we will take it from there.
|
Sun 27 Sep 2009 01:49:28 AM UTC, comment #5:
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.
|
Mon 01 May 2006 09:30:34 PM UTC, comment #4:
Hello Eli
Oah, that's quite a statement - needless to say we can't agree on the better or worse with different OS and compilers - BUT that's not really the issue here. As you said:
"WINDOWS32 should be used for OS- and runtime-dependent code"
Well, that's my point here. The use of this conditional here is not what was intended - the function prototypes have nothing to do with WIN32 specific code. And the macros need to be properly defined even on a non-WIN32 environment.
You have earlier supported the idea of a common conditional that will satisfy ANY compiler to replace the _STDC_ constant. The HAVE_ANSI_COMPILER is by my opinion an excellent candidat. Besides, look at changelog for 2004-03-06. And anyway, all this may go away with a new design of GNU make (hopefully).
As for your thoughts about Interix - interesting - I am preparing a post of a test of GNU make under Interix. I think the subject belong to the WIN32 mailing list, so I will post it there for anyone interested. Looking forward for any comment on that.
|
Mon 01 May 2006 06:40:21 PM UTC, comment #3:
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).
|
Mon 01 May 2006 03:21:28 PM UTC, comment #1:
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.
|
Mon 01 May 2006 12:50:34 PM UTC, original submission:
I'm slightly reluctant to mention this again, since you stated that a major change is planned to the next release. Meanwhile, I encountered the following inconsistencies when defining the function prototype macros (WINDOWS32 visavi HAVE_ANSI_COMPILER):
fnmatch.h(26) :
#if defined _cplusplus || (defined __STDC_ && _STDC_) || defined WINDOWS32
should be:
#if defined _cplusplus || (defined __STDC_ && _STDC_) || defined HAVE_ANSI_COMPILER
fnmatch.h(40) : the same
glob.h(26) : the same
hash.h(25) : the same
make.h(43) : #if defined (_cplusplus) || defined (__STDC_)
should be:
#if defined (_cplusplus) || defined (__STDC_) || defined HAVE_ANSI_COMPILER
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.
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
Note:
_STDC_ is reserved for strict posix compliance (or strict ANSI C as they state) in the MS compiler. It is somewhat safe (at least possible) to manually define it when compiling for Interix, but not when using the MS C runtime library.
|