On Mon, Oct 26, 2009 at 10:47 PM, Eli Zaretskii <e...@gnu.org> wrote:
>> From: Ozkan Sezer <invalid.nore...@gnu.org>
>> 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.
> Thanks for the other info.
>
My pleasure.
--
Ozkan
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
