Re: Compiling in mingw-ucrt runtime

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 23 Feb 2024 12:32:27 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> As mingw ucrt patch mentions; MS ucrt provides snprintf so mingw does not
> >> provide one in ucrt.
> >
> > Sorry, I don't understand what you mean by that.  MinGW only provides
> > some stuff that the MS libraries lack, so by "UCRT doesn't provide
> > _snprintf" I meant that the combination of MS ucrt and the MinGW
> > additions in UCRT mode doesn't provide _snprintf.
> 
> I meant they explained that in mingw runtime, msys/mingw provides their own
> implementation of snprintf, while in ucrt runtime it comes from Microsoft. If 
> I
> remember well from the time I uset to write some win32 code, Microsoft used 
> to prefix
> all posix functions with and underscore, so snprintf turned into
> _snprintf. Perhaps mingw just followed that convention by Microsoft. And now 
> in
> ucrt Microsoft don't underscore posix names? No idea really; just guessing. I 
> am
> not familiar with how msys/mingw folks do their patches and what is included 
> and
> what not. 

I can understand that UCRT doesn't provide _snprintf, but then I don't
see why all the calls of _snprintf in w32.c and w32fns.c don't cause
the same problems in the UCRT build.  Perhaps indeed some library is
linked into temacs.exe but not into cmdproxy.exe.

> >> Yes, I agree, it is all about close_stream. Seems like it is all the same 
> >> error:
> >> -1 (unspecified error). You can see the test from the patch.
> >> 
> >> I haven't seen the code for close_stream or msys patches; I will have to
> >> download and look at it; but it sounds plausible as you said that they 
> >> probably
> >> don't clean up errno.
> >
> > The source fore close_stream is in the lib/ subdirectory of the Emacs
> > source tree, so you should already have it.
> 
> Ah, I see. Thanks I'll look there. 

Thanks.