bugmake - Bugs: bug #16476, WINDOWS32 vs. HAVE_ANSI_COMPILER...

 
 

bug #16476: WINDOWS32 vs. HAVE_ANSI_COMPILER macros

Submitter:  Jerker Bäck <jerker_back>
Submitted:  Mon 01 May 2006 12:50:34 PM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  3.81 Operating System:  MS Windows
Fixed Release:  3.82 Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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.

Eli Zaretskii <eliz>
Group Member
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.

Paul D. Smith <psmith>
Group administrator
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.

Jerker Bäck <jerker_back>
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).

Eli Zaretskii <eliz>
Group Member
Mon 01 May 2006 03:38:56 PM UTC, comment #2: 

Well, for me the WINDOWS32 is rather annoying since I compile GNU make for Interix using the MS compiler (and therefore not using either WIN32 or WINDOWS32). Everytime I check out the code from CVS I have to look over, check and change the code for _STDC_ and WINDOWS32. It would be reassuring to know that the WIN32 (WINDOWS32) conditional is used only for WIN32 specific code and not for MS compiler compatiblity.

Jerker Bäck <jerker_back>
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.

J <now3d>
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.

Jerker Bäck <jerker_back>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by eliz (Posted a comment)
  • -email is unavailable- added by psmith (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-04-27 eliz Open/ClosedOpen Closed
        Fixed ReleaseNone 3.82
    2009-09-27 psmith SummaryInconsistent function macros - again WINDOWS32 vs. HAVE_ANSI_COMPILER macros
    2009-09-27 psmith Operating SystemAny MS Windows

    Back to the top

    Powered by Savane 3.13-0159.
    Corresponding source code