This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 64 bit Cygwin target and _WIN64


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.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]