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: Re: RFC: Cygwin 64 bit?


On Jun 28 13:33, Charles Wilson wrote:
> On 2:59 PM, Andy Koppe wrote:
> > On 27 June 2011 14:12, Eric Blake wrote:
> >> On 06/26/2011 06:10 AM, JonY wrote:
> >>>>   - Do we define "long" as 32 bit or 64 bit type?
> >>>
> >>> I suggest 32bit, they'll be some awkwardness accessing w32api at the
> >>> Cygwin backend if they're 64bit.
> >>
> >> I very much want LLP64 to match Linux; the _only_ software that should
> >> be accessing w32api in the cygwin backend is the cygwin dll itself,
> > 
> > Also cygutils, XWin, rxvt, mintty, and possibly more I'm not aware of.
> 
> Don't forget tcl/tk which is still kinda sorta not really cygwin.
> 
> And perl (at least, the perl-win32 extension), python, ruby(?),
> parrot(?), ... Lots of the interpreters seem to provide a binding to the
> Win32 API even when compiled "for" cygwin.

I still don't see the problem.  In how far is it valid to assume that
sizeof(long) == sizeof(LONG)?  long is a compiler intrinsic, LONG is
defined in a Windows header.  I don't see that the SDK claims that
there's a guarantee that long == LONG.  So, AFAICS, nothing speaks
against changing the w32api header to define LONG in a target dependent
way, for instance, and without gurantee for correctness:

  #ifdef __X86_64__
  typedef int LONG;
  typedef unsigned int ULONG, DWORD;
  #else
  typedef long LONG;
  typedef unsigned long ULONG, DWORD;
  #endif


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


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