This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
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