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?


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


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