Re: MPS: Win64 testers?

[Eli Zaretskii]

> Date: Sat, 27 Jul 2024 18:27:43 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: emacs-devel@gnu.org
> 
> On Saturday, July 27th, 2024 at 16:56, Eli Zaretskii <eliz@gnu.org> wrote:
> > 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?
> 
> _open_osfhandle returns 0 for the first FD, but _fdopen returns 0x7b281160, 
> while stdin is 0x7b281100.

Not on my system.  Here _fdopen returns a pointer to the same FILE
object as the original std* streams.  And it is also expected, since
the source code of MSVCRT explicitly shows that _fdopen calls a
routine that looks up a vacant stream slot, and that routine examines
the _iob[] array in the ascending order of indices, from zero to max,
until it finds an unused slot.

> I believe that _fdopen (0, "r") returns stdin if it has previously been 
> closed is an implementation detail of Windows that Emacs relies on, and that 
> wine fails to properly emulate. IMHO, this is a wine bug, but Emacs also 
> shouldn't rely on it unless it's documented as part of the API; I don't know 
> whether it is.

I believe this is how every Posix-like allocation of FILE objects
should behave.  I'm astonished that Wine doesn't work like that, since
it's the easiest way.

Moreover, the MS documentation says about the standard streams:

  These pointers are constants, and can't be assigned new values.

So you cannot do "stdin = _fdopen (...);" and hope for all the
references to stdin in the rest of the program to use the new value of
the stream pointer.  IOW, what Emacs does is the only way of doing
that.