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 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.

> > 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

> 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

> 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.


Corinna

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


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