Re: Problem when cross-compiling trunk in libgcc2.c

2009-03-19 Thread Ozkan Sezer
I'm a bit amazed that the prototype for VirtualProtect() is known to the
compiler but the definition of DWORD is not.. In any case, it should be
fixed easily by changing DWORD into unsigned int which is what a
DWORD is always defined as.  And PR 39063 is still open anyway.
--
Ozkan


Re: Problem when cross-compiling trunk in libgcc2.c

2009-03-19 Thread Ozkan Sezer
On Thu, Mar 19, 2009 at 8:04 PM, Vincent R.  wrote:
> On Thu, 19 Mar 2009 19:58:13 +0200, Ozkan Sezer  wrote:
>> I'm a bit amazed that the prototype for VirtualProtect() is known to the
>> compiler but the definition of DWORD is not.. In any case, it should be
>> fixed easily by changing DWORD into unsigned int which is what a
>> DWORD is always defined as.  And PR 39063 is still open anyway.
>> --
>> Ozkan
>
> Yes you are right about the fact VirtualProtect is defined and not DWORD so
> something is wrong with my includes

That is my guess..

> However you are wrong about DWORD definition it has always be defined
> like this :
>
> typedef unsigned long DWORD, *PDWORD, *LPDWORD;
>
> at least windows.
>

A DWORD on windows is an unsigned 32 bit integer, therefore even
if you use long, it won't matter because long is 32 bits for both win32
and for win64.

--

Ozkan


Re: Problem when cross-compiling trunk in libgcc2.c

2009-03-19 Thread Ozkan Sezer
On Thu, Mar 19, 2009 at 8:25 PM, Kai Tietz  wrote:
> 2009/3/19 Ozkan Sezer :
>> On Thu, Mar 19, 2009 at 8:04 PM, Vincent R.  wrote:
>>> On Thu, 19 Mar 2009 19:58:13 +0200, Ozkan Sezer  wrote:
>>>> I'm a bit amazed that the prototype for VirtualProtect() is known to the
>>>> compiler but the definition of DWORD is not.. In any case, it should be
>>>> fixed easily by changing DWORD into unsigned int which is what a
>>>> DWORD is always defined as.  And PR 39063 is still open anyway.
>>>> --
>>>> Ozkan
>>>
>>> Yes you are right about the fact VirtualProtect is defined and not DWORD so
>>> something is wrong with my includes
>>
>> That is my guess..
>>
>>> However you are wrong about DWORD definition it has always be defined
>>> like this :
>>>
>>> typedef unsigned long DWORD, *PDWORD, *LPDWORD;
>>>
>>> at least windows.
>>>
>>
>> A DWORD on windows is an unsigned 32 bit integer, therefore even
>> if you use long, it won't matter because long is 32 bits for both win32
>> and for win64.
>>
>> --
>>
>> Ozkan
>>
>
> Ozkan,
>
> Not, really. Because if the function was prototyped before by DWORD
> (for mingw/cygwin on x86/x64), we get a warning about different
> prototypes. For the compiler unsigned long and unsigned int are
> different types.
>

That was the reason I had specifically changed that int into a DWORD
and if the reporter's headers do have a problem, it still should stay that
way.

--
Ozkan