[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: |
Fri, 9 Jul 2010 15:30:09 +0300 |
On Fri, Jul 9, 2010 at 3:05 PM, Eli Zaretskii <address@hidden> wrote:
[snip]
>> > Thanks. I used almost all of the patches in w64-all-20100705.diff.
>> >
>>
>> Thanks for applying the patches.
>>
>> There are some issues, though:
>
> I forgot to send these upstream, now fixed.
>
Thanks.
In make.h, the w32_kill prototpe sitll needs updating, though, like:
-int w32_kill (int pid, int sig);
+int w32_kill (pid_t pid, int sig);
... otherwise build fails.
>> * w32/subproc/sub_proc.c: Handles & pids still used with int types
>> which really must be intptr_t types as suggested in the patch. See
>> these warnings:
>
> Didn't you need to include stdint.h for these? If not, where did GCC
> get the definition of intptr_t?
There are many other headers who silently include stdint.h
such as process.h. I see that you already included stdint.h
in subproc.c, but for completeness' sake, you may want to
consider something like:
+#ifdef _MSC_VER
+#include <stddef.h>
+#else
#include <stdint.h>
+#endif
... because M$VC doesn't have a stdint.h
>
>> > There's one issue -- with declaration of alloca -- that awaits Paul's
>> > response, since I don't think we should include malloc.h.
>> >
>>
>> This one:
>> http://lists.gnu.org/archive/html/bug-make/2010-07/msg00054.html
>> ... yes?
>
> Yes, I'm waiting for Paul to respond on this one.
>
Here are some more nitpicking:
* job.c (pid2str): No need for __GNUC__ > 3 because gcc-3.4.5
of mingw.org can handle these, too. Besides, it is ruling out
the possibility of M$VC compiler.
* job.c (exec_command): Instead of casting the handles to
DWORD_PTR, it would be more appropriate casting them to pid_t,
ie. changing those two (DWORD_PTR)hWaitPID to (pid_t)hWaitPID
... because pid2str() already accepts pid_t argument.
* main.c: You may want to pacify the compiler for the ADD_SIG
macro, too, as I did in my suggested patch, something like:
#define ADD_SIG(sig) fatal_signal_mask |= sigmask (sig)
#else
-#define ADD_SIG(sig) (void)sig
+#define ADD_SIG(sig)
#endif
#endif
(not much of a problem, but . avoids annoying statement with
no effect warnings.)
--
Ozkan
- [bug #27809] several win64 fixes, (continued)
- [bug #27809] several win64 fixes, Ozkan Sezer, 2010/07/05
- [bug #27809] several win64 fixes, Paul D. Smith, 2010/07/05
- [bug #27809] several win64 fixes, Eli Zaretskii, 2010/07/09
- [bug #27809] several win64 fixes, Eli Zaretskii, 2010/07/09
- [bug #27809] several win64 fixes, Paul D. Smith, 2010/07/09
- [bug #27809] several win64 fixes, Paul D. Smith, 2010/07/09
- [bug #27809] several win64 fixes, Ozkan Sezer, 2010/07/09
- Re: [bug #27809] several win64 fixes, Eli Zaretskii, 2010/07/09
- Re: [bug #27809] several win64 fixes, Ozkan Sezer, 2010/07/09
- Re: [bug #27809] several win64 fixes, Eli Zaretskii, 2010/07/09
- Re: [bug #27809] several win64 fixes,
Ozkan Sezer <=
- Re: [bug #27809] several win64 fixes, Eli Zaretskii, 2010/07/09
Re: [bug #27809] several win64 fixes, Edward Welbourne, 2010/07/05