bug-make
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]