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


I've been reading with much interest the posts of this thread.  To help
control which libraries are used by which programs and allow one Cygwin
DLL to control both we could consider two differing entry points into
the DLL, the existing one for 32bit and a new one for 64bit.  Cygwin
would then know which pointer size to use because the initialization
would be different.  Would this work, I don't know but thought I would
throw the idea into the mix.

I was quite shocked when I stumbled across to variants LP64 vs LLP64 and
to learn that the long data type might represent 32 bits.  That was
just, well, ignorant and I agree that the sizeof(long) == sizeof(void *)
makes sense except for the fact that the C standard states in the final
draft version in section 5.2.4.2.1 the size of data type long is 2^32 -
1 and defines long long as 2^64 - 1.  It doesn't account for the
variance in the sizeof(void *) except to say that it is equivalent to
size of any other pointer of any other data type.  Because of this LLP64
makes a lot of sense.  But I agree that Cygwin has to bridge the two
variants since LP64 is used by Linux systems and allow for the data type
to shift from the C standard and use this model but the data type still
need to follow bit size pattern of char < short < int < long == pointer
< long long.  While the native ``MinGW'' should follow the LLP64 model
for the bit size pattern of char < short < int < long < pointer == long
long.


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