hello,
Thanks for the answers, I'm trying to keep up / follow.
> Are the programs in question using the fclose module, either directly or
indirectly?
Well, simply doing `m4.exe --version` does exhibit the issue. Not sure if
I'm answering the question correctly or not.
I'm looking at the close-out.c, which calls close-stream.c
In close_stream, shouldn't the stdout FILE * be set to NULL if the close
worked, so that in the event it's called a second time you can first check
if stream == NULL?
Something like this:
diff --git a/lib/close-stream.c b/lib/close-stream.c
index 86f6d6e1d..432907a0c 100644--- a/lib/close-stream.c+++
b/lib/close-stream.c@@ -55,6 +55,7 @@
int
close_stream (FILE *stream)
{+ if (stream != NULL) {
const bool some_pending = (__fpending (stream) != 0);
const bool prev_fail = (ferror (stream) != 0);
const bool fclose_fail = (fclose (stream) != 0);
@@ -69,10 +70,12 @@ close_stream (FILE *stream)
if (prev_fail || (fclose_fail && (some_pending || errno != EBADF)))
{- if (! fclose_fail)+ if (! fclose_fail) {
errno = 0;+ stream = NULL;+ }
return EOF;
}
+ }
return 0;
}
Best,
Julien
--
Julien Marrec, EBCP, BPI MFBA
Owner at EffiBEM <http://www.effibem.com>
T: +33 6 95 14 42 13
LinkedIn (en <https://www.linkedin.com/in/julienmarrec>) *| *(fr
<https://fr.linkedin.com/in/julienmarrec/fr>) :
<http://www.linkedin.com/in/julienmarrec>
Le mar. 25 janv. 2022 à 22:33, Paul Eggert <egg...@cs.ucla.edu> a écrit :
> On 1/25/22 08:13, Eric Blake wrote:
> > it something that gnulib should work around by
> > overriding fclose() to be guaranteed that it has an open fd?
>
> This is a bug that Gnulib's fclose module is already supposed to be
> working around. Are the programs in question using the fclose module,
> either directly or indirectly? If so, we should investigate why the
> fclose module isn't working around the MSVC bug. If not, perhaps we
> should change the close-stream module to start depending on the fclose
> module.
>
