ForkThe simple test program below almost always fails on my system.
"Almost always" means that it succeeds to create and open a temporary
file once every 6 invocations, on the average, and fails for all the
rest. When it fails, the value of errno is mostly EINVAL, but on a
couple of occasions I saw ENOENT.
If I step with a debugger into __mingw_mkstemp, I see that
__mingw_crypto_tmpname in most cases generates a file name that is
invalid on Windows filesystems: it includes characters whose value is
below 32, and trying to create such files fails with EINVAL. I'm
guessing that the few cases where I saw ENOENT were because the
generated file name included characters above decimal 31, but those
which are not allowed, like a slash or a backslash. And since
__mingw_mkstemp only retries with a different file name if the error
is EEXIST, it bails out immediately after trying such file names.
This is with the latest MinGW runtime 5.2 on a Windows XP system, with
MinGW GCC 7.3.0 and Binutils 2.31.1.
Did I miss something obvious, or is this a real bug?
Here's the test program. Invoke it with a single argument that is the
base-name part of the template to be passed to mkstemp, like "XXXXXX"
or "fooXXXXXX".
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int
main (int argc, char *argv[])
{
if (argc > 1)
{
char tmpl[FILENAME_MAX];
char *tev = getenv ("TMPDIR");
if (!tev)
tev = getenv ("TEMP");
if (tev)
{
int fd;
strcpy (tmpl, tev);
strcat (tmpl, "/");
strcat (tmpl, argv[1]);
fd = mkstemp (tmpl);
printf ("%s => fd: %d\n", tmpl, fd);
}
else
fprintf (stderr, "No usable TMP variable!\n");
}
return 0;
}