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 10:19 AM, Corinna Vinschen wrote:
> On Jan 18 10:55, Corinna Vinschen wrote:
>> On Jan 18 17:25, JonY wrote:
>>> On 1/18/2012 17:02, Kai Tietz wrote:
>>>> To use here __CYGWIN__ as marker in platform-headers seems to me
>>>> wrong.  But compiler defines for LP64 IIRC already __LP64__ makro (or
>>>> if it doesn't we could teach it to do so along with __LLP64__).
>>
>> Right, at least gcc 4.6.2 on Linux defines __LP64__ and _LP64.
>> x86_64-w64-mingw32-gcc 4.5.3 does not defined __LLP64__ or _LLP64,
>> though.  Maybe it has only been added in gcc 4.6?
> 
> No, apparently not.  Only if gcc is built for LP64, the aforementioned
> macros are defined.  There's no LLP64 define.  However, if the #pragma
> idea isn't feasible, we could also fall back to the existing definition
> of __SIZEOF_LONG__.

Not sure the extend of the effects of the pragma you indended, but
you can do today:

  typedef unsigned long DWORD __attribute__ ((mode(SI)));
  typedef DWORD *LPDWORD;

to force DWORD to 32-bit everywhere.   But then, why not just always
do

  typedef unsigned int DWORD, *LPDWORD;

?

>  #include <windows.h>
>
>  int
>  main (int argc, char **argv)
>  {
>    unsigned long type;
>    GetBinaryTypeA (argv[1], &type);
>  }
> This would work in the LLP64 model, but it would and should result in a
> type mismatch on a LP64 compiler.

I don't see how the pragma would fix this, but you didn't intend it to,
right?  The fix is "Don't do that then.  Use DWORD instead.".

-- 
Pedro Alves


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