Re: MinGW open-process, take N

[Eli Zaretskii]

> From: Andy Wingo <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> Date: Tue, 12 Jul 2016 16:05:35 +0200
> 
> > It's hard for me to build Guile from Git, due to the additional
> > prerequisites that needs.
> 
> Understood, in that case please note that there is also an automatic
> build service that runs "make" and "make dist" to make tarballs:
> 
>   https://hydra.nixos.org/job/gnu/guile-2-0/tarball
> 
> Just click through and you can download a tarball.  For example:
> 
>   
> https://hydra.nixos.org/build/37557639/download/3/guile-2.0.11.238-e1cb7.tar.gz
> 
> There is .xz too.  This service exists for Guile master too:
> 
>   https://hydra.nixos.org/job/gnu/guile-master/tarball

Thanks, I will try that when I have time, if Guile is not released
before that.

>   getuid is used in boot-9.scm, so if it's unavailable, we cannot build
>   Guile without making changes in the Scheme code.  I don't know if that
>   convinces you, and I have no practical way of counting their uses in
>   Guile programs outside Guile itself.
> 
> But in reality the getuid is of this form:
> 
>   (define (load-user-init)
>     (let* ((home (or (getenv "HOME")
>                      (false-if-exception (passwd:dir (getpwuid (getuid))))
>                      file-name-separator-string))  ;; fallback for cygwin etc.
>            (init-file (in-vicinity home ".guile")))
>       (if (file-exists? init-file)
>           (primitive-load init-file))))
> 
> So, no problem.

Won't this fail to compile during boot, or at least produce a warning?

> > 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.
> 
> Hummmm, I don't know, there are a number of other things in that file
> which treat PIDs as ints (scm_waitpid, scm_getppid, etc etc etc).  I
> think that would need to be another patch that adds scm_from_pid_t and
> scm_to_pid_t and so on.  And then what is this?
> 
>   http://permalink.gmane.org/gmane.comp.gnu.mingw.w64.general/12235

The process ID is indeed an int, but my code hides a process handle
inside it.

> I will apply your patch though and I look forward to hearing if it works
> for you :)

The above is not a problem for me, since I use the 32-bit MinGW, where
a handle is a 32-bit type.  This is only a potential problem in 64-bit
builds.

Thanks.