This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: RFC: Cygwin 64 bit?
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