[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #27809] several win64 fixes
From: |
Ozkan Sezer |
Subject: |
[bug #27809] several win64 fixes |
Date: |
Mon, 26 Oct 2009 22:44:16 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009061118 Fedora/3.0.11-1.fc9 Firefox/3.0.11 |
Follow-up Comment #4, bug #27809 (project make):
[ I forgot replying from within the bug tracker.
sorry if this becomes a duplicate. ]
>> > 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.
>>
>> -mthreads : This one is a noop for mingw-w64 crt.
>
> This is needed to properly handle Ctrl-C, since (at least on w32) the
> signal handler runs in a separate thread. So what happens in a w64
> build of Make if you press Ctrl-C while Make runs? Does it behave as
> expected (read: as on Posix systems)?
>
Just tried running a makefile with it (under an msys console) and it
just exists.
> Thanks for the other info.
>
My pleasure.
--
Ozkan
(file #18947)
_______________________________________________________
Additional Item Attachment:
File name: mingw-buildlogs-diff.txt Size:15 KB
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?27809>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [bug #27809] several win64 fixes, Ozkan Sezer, 2009/10/26
- [bug #27809] several win64 fixes, Eli Zaretskii, 2009/10/26
- Re: [bug #27809] several win64 fixes, Eli Zaretskii, 2009/10/26
- RE: [bug #27809] several win64 fixes, Martin Dorey, 2009/10/26
- Re: [bug #27809] several win64 fixes, Ozkan Sezer, 2009/10/26
- Re: [bug #27809] several win64 fixes, Ozkan Sezer, 2009/10/26