RFC: Cygwin 64 bit?

Corinna Vinschen corinna-cygwin@cygwin.com
Mon Jun 27 15:33:00 GMT 2011


On Jun 27 07: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

Erm... LP?  LLP is Windows...

> be accessing w32api in the cygwin backend is the cygwin dll itself,
> which can take its own precautions to do correct conversions, whereas
> everything compiled against the cygwin dll will be easier to port if it
> remains like Linux with sizeof(long)==sizeof(void*).
> 
> I also hope that we can use this as an opportunity to move to 64-bit
> time_t and NSIG of 64, even on 32-bit cygwin, which will be an ABI
> change (similar to when we moved from stat to stat64 for the off_t ABI
> change).

I'm not against this but it needs somebody to do it.

> And as long as we are considering an ABI change, should we consider
> moving to 4-byte wchar_t to match Linux?

Actually I'm not considering an ABI change.  A 64 bit Cygwin would
be another platform, kind of.  That means a 64 bit DLL does not
change the ABI, it's just a new ABI for a platform we didn't have one
before.

Changing wchar_t is quite a beast.  As much as I like to have 4 byte
wchar_t, it requires a very intrusive change in Cygwin with lots of
code changes.  And you can't do that on 32 bit unless you change the
toolchain since wchar_t is defined in gcc.  And if you do it on 64
bit only, you'll probably get lots and lots of #ifdefs.  Very tricky,
that one.


Corinna

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



More information about the Cygwin-developers mailing list