guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MinGW open-process, take N


From: Eli Zaretskii
Subject: Re: MinGW open-process, take N
Date: Tue, 12 Jul 2016 16:02:56 +0300

> From: Andy Wingo <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> Date: Mon, 11 Jul 2016 23:51:17 +0200
> 
> I have reworked Guile a bit in anticipation of your patch and in the end
> reworked your patch a bit too.  Please fetch git and see how things are
> working for you, first -- it could be I introduced a MinGW bug.  Then
> here attached is your patch, reworked.  Let me know how it looks to
> you.  If it looks good I'll apply and release in 2.0.12 tomorrow or so.

Thanks.

It's hard for me to build Guile from Git, due to the additional
prerequisites that needs.

Instead, I reviewed the changes, comparing them with my original
patch.

First, I see that you also removed getuid and getgid; I believe we
only talked about removing setuid and setgid.  As I said, getuid is
needed to build Guile.

The only other issue I see is the type of the value returned by
start_child, and as result by scm_open_process.  On Windows, the value
returned has the type HANDLE, which is actually a pointer in disguise.
I used intptr_t for that, but you changed it to just int.  This will
not work in 64-bit MinGW builds, where a pointer is a 64-bit type.  I
think we should go back to intptr_t, and also change the conversion to
the value returned by scm_open_process, since scm_from_int will AFAIK
not support 64-bit integer types.  Note that the MinGW waitpid
implementation also expects to get a valu that is interpreted as a
handle.

Other than that, the changes look good, and I will certainly try to
build Guile 2.0.12 when it is released.

Thanks.



reply via email to

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