[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #27809] several win64 fixes
From: |
Ozkan Sezer |
Subject: |
Re: [bug #27809] several win64 fixes |
Date: |
Mon, 26 Oct 2009 23:46:34 +0200 |
On Mon, Oct 26, 2009 at 11:21 PM, Ozkan Sezer <address@hidden> wrote:
> On Mon, Oct 26, 2009 at 10:47 PM, Eli Zaretskii <address@hidden> wrote:
>>> From: Ozkan Sezer <address@hidden>
>>> Date: Mon, 26 Oct 2009 19:20:27 +0000
>>>
>>>
>>> > 3. Why did you need casts in assignments, like this:
>>> >
>>> > - *pid_p = (int) hProcess;
>>> > + *pid_p = (pid_t) hProcess;
>>> >
>>>
>>> Because you are casting a handle, which is a ptr*, to an int.
>>
>> But you change pid_p to point to a pid_t type, which is no longer an
>> int on a 64-bit host. So why can't you get rid of the cast
>> altogether, like this:
>>
>> pid_p = hProcess;
>>
>> ? Does this work on w64?
>>
>
> Well,
>
> typedef struct _PROCESS_INFORMATION {
> HANDLE hProcess;
> HANDLE hThread;
> DWORD dwProcessId;
> DWORD dwThreadId;
> } PROCESS_INFORMATION,*PPROCESS_INFORMATION,*LPPROCESS_INFORMATION;
>
> hProcess is HANDLE here, but your pid_p is int in your
> original version or pid_t in my version. Without casting
> you'll get warnings from the compiler.
>
>>> > 4. This change:
>>> >
>>> > - pipedes[0] = _open_osfhandle((long) hChildOutRd, O_RDONLY);
>>> > + pipedes[0] = _open_osfhandle((intptr_t) hChildOutRd, O_RDONLY);
>>> >
>>> > assumes that _open_osfhandle accepts an intptr_t type as its first
>>> argument.
>>> > But the prototype I have on my machine (in io.h) says the first argument
>>> > is
>>> a
>>> > `long'. Which version of MinGW changed that?
>>>
>>> It is the same case. Your version is for w32-only.
>>> The mingw-w64 version is like (from io.h):
>>> _CRTIMP int __cdecl _open_osfhandle(intptr_t _OSFileHandle,int _Flags);
>>
>> But that means I cannot simply apply your patch, because users of
>> MinGW will then complain about compiler warnings, right?
>>
>
> How so?? MinGW does provide intptr_t, I really can't see the
> problem here.
>
... and, for the record, I just built the make-cvs for mingw.org,
without and with my patch applied, there seems to be no new
warnings generated (and many of the alloca warnings are just
cured.) Attaching a diff of build logs.
--
Ozkan
>> Thanks for the other info.
>>
>
> My pleasure.
>
> --
> Ozkan
>
01.diff.gz
Description: GNU Zip compressed data