Re: Compiling in mingw-ucrt runtime

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Feb 2024 12:40:56 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Arthur Miller <arthur.miller@live.com>
> >> Cc: emacs-devel@gnu.org
> >> Date: Sun, 25 Feb 2024 11:19:58 +0100
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> >> >   const bool some_pending = (__fpending (stream) != 0);
> >> >> >   const bool prev_fail = (ferror (stream) != 0);
> >> >> >   const bool fclose_fail = (fclose (stream) != 0);
> >> >> 
> >> >> prev_fail sometimes fail with Operation not permitted.
> >> >> fclose fails always with -1
> >> >
> >> > What is the value of errno before and after fclose, in particular when
> >> > ferror does NOT fail (i.e. prev_fail is false)?
> >> 
> >> fclose *always* fail with -1. All calls to fclose are -1. I don't see any 
> >> call
> >> to fclose that does not return -1. Both when prev_fails is EPERM and when
> >> prev_fail does not fail.
> >
> > OK, but I asked also about the value of errno _after_ fclose is called
> > and fails.  It's important for understanding why it fails.
> 
> You got the ansewr: -1; always after fclose :). It seem to never succeed.
> 
> c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: FPENDING:: No error
> c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: PREV-FAIL:: No error
> c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: FCLOSE:: Unidentified 
> error: -1
> c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: Write error to standard 
> output: Unidentified error: -1
> c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: FPENDING:: No error
> c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: PREV-FAIL:: Operation not 
> permitted
> c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: FCLOSE:: Unidentified 
> error: -1
> c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: Write error to standard 
> output: Unidentified error: -1
> Compilation finished.
> 
> I did this little abomination:
> 
> #include <fpending.h>
> int
> close_stream (FILE *stream)
> {
>   /* const int some_pending = (__fpending (stream) != 0); */
>   /* const int prev_fail = (ferror (stream) != 0); */
>   /* const int fclose_fail = (fclose (stream) != 0); */
> 
>   const int some_pending = __fpending (stream);
>   emacs_perror ("FPENDING:");
>   const int prev_fail    = ferror (stream);
>   emacs_perror ("FPREV:");
>   const int fclose_fail  = fclose (stream);
>   emacs_perror ("FCLOSE:");
>   /* Return an error indication if there was a previous failure or if
>      fclose failed, with one exception: ignore an fclose failure if
>      there was no previous error, no data remains to be flushed, and
>      fclose failed with EBADF.  That can happen when a program like cp
>      is invoked like this 'cp a b >&-' (i.e., with standard output
>      closed) and doesn't generate any output (hence no previous error
>      and nothing to be flushed).  */
> 
>   if (prev_fail || (fclose_fail && (some_pending || errno != EBADF)))
>     {
>       if (! fclose_fail)
>         errno = 0;
>       return EOF;
>     }
> 
>   return 0;
> }
> 
> (moved it to sysdep.c)
> 
> Everytime native compiler compiles a file, and Emacs exits I get this, so I
> guess it is from closing the process?

Time to involve the Gnulib folks, I think.

Bruno, are you aware of these issues with MinGW UCRT builds?  Why does
fclose fail, leaving errno at -1?

> So it perhaps has nothing to do with snprintf at all?

It's unrelated to snprintf.

> >> I understand; thanks. I guess I should learn nm tool.
> >> 
> >> Which one shold be correct than: should sydep.c use stuff from ucrt dll; or
> >> should it use the built-in stuff?
> >
> > Sorry, I don't understand: what about sysdep.c?  If you are talking
> > about close_output_streams, then we are not done yet investigating why
> 
> I meant in general; should temacs/emacs also use snprintf/_vsnprintf
> from ucrt runtime or one that comes with Emacs/gnulib? 

We already use the snprintf from UCRT, because we include stdio.h.

> >> $ time make bootstrap -j12
> >> 
> >> real    12m40.651s
> >> user    2m46.900s
> >> sys     1m19.613s
> >
> > Well, you have 1/3rd of execution units I have, so 12 min is
> > reasonable, especially if this is with native-compilation.
> 
> So what are you saying: that thes "efficient cores" as intel sells them are 
> just
> paperweight? :-) Basically it is a dual-core machine than?

It has about 12 execution units, AFAIU.