Re: Compiling in mingw-ucrt runtime

[Eli Zaretskii <eliz@gnu.org>]

> From: Bruno Haible <bruno@clisp.org>
> Cc: arthur.miller@live.com, emacs-devel@gnu.org
> Date: Sun, 25 Feb 2024 16:32:59 +0100
> 
> On Sonntag, 25. Februar 2024 16:14:51 CET Eli Zaretskii wrote:
> > > From: Bruno Haible <bruno@clisp.org>
> > > Cc: arthur.miller@live.com, emacs-devel@gnu.org
> > > Date: Sun, 25 Feb 2024 16:05:54 +0100
> > > 
> > > > Strange that they claim that, because their sources tell a different
> > > > story, both for MSVCRT and for UCRT.  Or maybe your interpretation of
> > > > what they say there is inaccurate?
> > > 
> > > Re MSVCRT: My reading of Vc7/crt/src/fclose.c is that it never sets errno.
> > 
> > fclose.c doesn't, indeed, but it calls _close (in close.c), which
> > does.
> 
> OK, so when it calls _close() and that fails, errno gets set. Good.
> Still, fclose() can also fail due to !inuse(stream), in which case errno does
> not get set.
> 
> > > Re UCRT: My reading of ucrt-10.0.10240.0/stdio/fclose.cpp
> > > and 10.0.14393.0/ucrt/stdio/fclose.cpp
> > > is that errno gets set to EINVAL if the stream argument is invalid,
> > > and remains unchanged otherwise.
> > 
> > I do see errno being set in close.cpp, which fclose.cpp calls to do
> > the actual job.
> 
> Likewise here: Still, fclose() can also fail due to !stream.is_in_use(), in
> which case errno does not get set.

Yes, I agree that it doesn't set errno in all the cases where it
fails.  But that's a far cry from saying that errno is always
undefined after it fails.

And the question still stands why does it fail in Emacs in such a way.