Re: MPS: Win64 testers?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 27 Jul 2024 19:10:50 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > I think the problem is init_ntproc in w32.c, which closes stdin, stdout, stderr, then calls _fdopen and assumes the result will live in stdin, stdout, stderr again. If I disable that code the backtick problem goes away:
> > 
> >     fclose (stdin);
> >     fclose (stdout);
> >     fclose (stderr);
> > 
> >     if (stdin_save != INVALID_HANDLE_VALUE)
> >       _open_osfhandle ((intptr_t) stdin_save, O_TEXT);
> >     else
> >       _open ("nul", O_TEXT | O_NOINHERIT | O_RDONLY);
> >     _fdopen (0, "r");
> 
> Why do you think it's a problem?  And why do you think the assumption
> of fdopen is incorrect?  It is confirmed by the source code of MSVCRT.
> 
> > I believe that last line should, possibly, on some systems, be
> > 
> >     stdin = _fdopen (0, "r");
> > 
> > but I'm not sure the variable (or macro) stdin is an lvalue. That's probably why close_stream(stdout) and close_stream(stderr) fail, too: the streams they refer to are already closed, and the new streams we should be using instead were discarded.
> 
> But this never fails in MinGW builds on Windows.

And if I change w32.c like below:

diff --git a/src/w32.c b/src/w32.c
index 31ffa30..c28a234 100644
--- a/src/w32.c
+++ b/src/w32.c
@@ -10517,20 +10517,21 @@ init_ntproc (int dumping)
     fclose (stdout);
     fclose (stderr);
 
+    int fd;
     if (stdin_save != INVALID_HANDLE_VALUE)
-      _open_osfhandle ((intptr_t) stdin_save, O_TEXT);
+      fd = _open_osfhandle ((intptr_t) stdin_save, O_TEXT);
     else
       _open ("nul", O_TEXT | O_NOINHERIT | O_RDONLY);
     _fdopen (0, "r");
 
     if (stdout_save != INVALID_HANDLE_VALUE)
-      _open_osfhandle ((intptr_t) stdout_save, O_TEXT);
+      fd = _open_osfhandle ((intptr_t) stdout_save, O_TEXT);
     else
       _open ("nul", O_TEXT | O_NOINHERIT | O_WRONLY);
     _fdopen (1, "w");
 
     if (stderr_save != INVALID_HANDLE_VALUE)
-      _open_osfhandle ((intptr_t) stderr_save, O_TEXT);
+      fd = _open_osfhandle ((intptr_t) stderr_save, O_TEXT);
     else
       _open ("nul", O_TEXT | O_NOINHERIT | O_WRONLY);
     _fdopen (2, "w");

then stepping through this code I see that fd is first assigned zero,
then 1, then 2.  As expected, because any decent emulation of Posix
file descriptors must keep this semantics: file descriptors are reused
starting from the lowest available slot.

Do you see something different in your build?