Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <433AB3B3.9030208@cwilson.fastmail.fm>
Date: Wed, 28 Sep 2005 11:16:03 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: Cygwin List <cygwin AT cygwin DOT com>
Subject: Re: Strange behaviour with g++ 3.4.4-1
References: <Pine DOT OSF DOT 4 DOT 21 DOT 0509262334460 DOT 24737-100000 AT ax0rm1 DOT roma1 DOT infn DOT it>  <Xns96DE984C3CBC5ajmrtmi AT 80 DOT 91 DOT 229 DOT 5>  <433A9054 DOT 7000202 AT byu DOT net> <6 DOT 2 DOT 1 DOT 2 DOT 0 DOT 20050928105005 DOT 0443a958 AT pop DOT prospeed DOT net>
In-Reply-To: <6.2.1.2.0.20050928105005.0443a958@pop.prospeed.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Larry Hall wrote:
> At 08:45 AM 9/28/2005, you wrote:
>>  The correct fix, in my opinion, would be to update windef.h to not
>>define min and max if __cplusplus is defined, since C++ is much less
>>forgiving of min and max being macros in the first place (in other words,
>>min and max as macros only works in C).
>>
>>But where does upstream windef.h live, to propose a patch to it?
> 
> 
> 
> Isn't it enough to offer a patch to the w32api package maintainer and let
> that person take this upstream?

I disagree with any proposed "fix" for this behavior.  The simple fact 
is, the actual Microsoft headers (the ones shipped with MSVC) behave the 
way the current w32api package headers do.

Poorly.

But, if we "fix" w32api, then we're no longer bug-for-bug compatible 
with MSVC -- which means, if you want to compile software written in/for 
MSVC, it will behave differently when compiled using mingw or MSYS or 
cygwin -mno-cygwin.  This would be a bad thing.

If you're using windows facilities (e.g. #including <windows.h>, then 
you need to understand what that means -- and code appropriately.  I 
really don't understand why this simple question, which is answered all 
OVER the freakin' googlenet, has spawned such a huge thread here.

#define NOMINMAX
#include <windows.h>

It's real simple, folks.

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/