This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: RFC: Cygwin 64 bit?
On 01/18/2012 01:57 PM, Corinna Vinschen wrote:
> On Jan 18 12:34, Pedro Alves wrote:
>> On 01/18/2012 11:54 AM, Corinna Vinschen wrote:
>>> Apart from the fact that Microsoft defines DWORD as unsigned long, which leads to
>>> the question how close to the orignal source the Mingw64 headers are supposed to be,
>>
>> Okay question on LP64 mode, but there are no original LLP64 sources, though, and
>> there likely won't be.
>
> Can you explain? I don't understand what you mean by "there are no
> original LLP64 sources". The Windows headers in their original and
> current state require the usage of an LLP64 compiler to work correctly.
Whoops, obviously I switched LP64 and LLP64 around.
So I meant, "okay question on LLP64 mode, but there are no original LP64
sources, though, and there likely won't be."
>
>>> there's also the problem that not all Windows functions and struct/union definitions
>>> use the Windows types. For example the esent.h header defines the
>>> struct JET_SIGNATURE like this:
>>>
>>> typedef struct _JET_SIGNATURE {
>>> unsigned long ulRandom;
>>> JET_LOGTIME logtimeCreate;
>>> char szComputerName[JET_MAX_COMPUTERNAME_LENGTH + 1];
>>> } JET_SIGNATURE;
>>>
>>> and this is equivalent to how it's defined in the Visual C++ header.
>>> So, just redefining LONG, ULONG, DWORD, etc is only half the solution
>>> unfortunately.
>>
>> With the pragma, I think you'd still get a -Wall/-Wformat warning
>> in LLP64 for
>>
>> JET_SIGNATURE js;
>> printf ("%ld", fs.ulRandom);
>
> No, you'd get the warning in LP64. The printf should be fine for LLP64
Right, my point still stands.
>
>> so you can't have a perfect match, and some things will always
>> need adjustment. The question is then, is
>>
>> #if LLP64
>> unsigned int ulRandom;
>> #else
>> unsigned long ulRandom;
>> #endif
>
> Er... is it possible that you switched the meaning of LP64 and LLP64?
> http://en.wikipedia.org/wiki/64-bit#64-bit_data_models
Yes.
>
>> any worse?
>
> Well, there's a big difference. If you have to do the above,
> you have to change lots and lots of places in the header files.
> The #pragma only requires a dumb adding of two #pragma directives
> at the start and end of each header file, which can be easily
> automated. It's also much less intrusive.
I was looking for a technical reason that's worse, other then the
amount of mechanical work, which I'm sure could also be easily
scripted, with the long/int hidden behind a #define,
from the perspective of code that uses the headers. It's obvious
the pragma is less intrusive to the headers.
--
Pedro Alves