64 bit Cygwin target and _WIN64

Earnie Boyd earnie@users.sourceforge.net
Wed Jul 18 12:36:00 GMT 2012

On Wed, Jul 18, 2012 at 7:03 AM, Corinna Vinschen wrote:
> Hi guys,
> Here's a problem I need feedback for.
> I'm currently working on making Mingw64 headers 64 bit Cygwin aware.
> One, IMHO pretty tough problem is the definition of _WIN64.
> A Cygwin-targeting gcc does not define WIN32, _WIN32, __WIN32 and
> __WIN32__ by default.  The original reason is that we had (and probably
> still have) a lot of projects, which test for _WIN32 one way or the
> other to decide if a POSIX or a Windows function should be called,
> the latter typically to be avoided.
> Now comes the time for _WIN64.  _WIN64 is used a *LOT* inside of the
> Mingw64 headers to distinguish type definitions which differ from the
> 32 bit version, or to declare functions which only exist on 64 bit
> machines, stuff like that.

Is it needed always or just during compilation of Cygwin? (but read on
before answering)

> There are a couple of ways to help us along with this problem:
> 1. Replace all
>     #ifdef _WIN64
>    with
>     #if defined (_WIN64) || defined (__CYGWIN64__)

Ugly, what happens now with _WIN32 headers?

> 2. In a core Mingw64 header:
>     #if defined (_WIN64) || defined (__CYGWIN64__)
>     #define _WINX64
>     #endif
>    Then replace all `#ifdef _WIN64' with `#ifdef _WINX64'.

I don't see this happening; too easy to break.

> 3. In a core Mingw64 header:
>     #ifdef __CYGWIN64__
>     #define _WIN64
>     #endif

If you only need _WIN64 defined during the Cygwin build then put this
in a Cygwin local definition else put it in the mingw64 headers.

> 4. Let the Cygwin 64 bit gcc define _WIN64 by default.
> I think all of these variations have up- and downsides.  I just can't
> decide which is the best way to handle the problem.  So, let me tell
> you what I think and then chime in, please:
> 1. Most straightforward, but uglifies the headers extremly.  All
>    later added ifdefs have to be checked so that they don't exclude
>    __CYGWIN64__.
> 2. Better than 1 as far as readability and ugliness are concerned.
>    But also requires constant vigilance so that _WIN64 doesn't creep in
>    again.
> 3. If _WIN64 is defined in a Mingw64 header, then all projects which
>    don't include windows headers are off the hook.  configure is off
>    the hook as well.  Only projects which use `#ifdef _WIN64' within
>    the code may be in trouble.
> 4. What can I say?  This is exaclty the situation we'd like to avoid.
> Concerning point 3 and 4, the question on the Mingw64 IRC channel was
> this:  Is that really a serious problem?  Projects testing for windows
> targets usually test for _WIN32, not for _WIN64, since _WIN32 is always
> defined, on 32 and on 64 bit Windows.

I would argue that point, I could see some project use _WIN64 for
specific abilities of the API.  Yes both are defined by default.

> Consequentially, projects for which testing for _WIN64 is an important
> design choice are windows-centric anyway and probably no serious target
> for a Cygwin port.

Maybe not always though.  As _WIN64 specifics begin to creep into
those now supporting _WIN32.

> Given that, I am inclined to simplify the problem by choosing point 3;
> just define _WIN64 if a Windows header is included and then keep it
> at that.

I like this.  If it is always needed then do it in the mingw64 headers
otherwise do it locally.

-- https://sites.google.com/site/earnieboyd

More information about the Cygwin-developers mailing list