Hi, It seems the underlying implementation of mskstemp is different between glibc and gnulib. Specifically, in tempname.c function try_tempname_len. The local variable v of type random_value is initialized to 0 in gnulib:
/* A random variable. */ random_value v = 0; whereas in glibc the following little trick is done: random_value v = ((uintptr_t) &v) / alignof (max_align_t); This is then used as a parameter to function random_bits. I didn't debug this on Windows (I honestly don't even know how, I'm simply using a gcc release from winlibs ie. https://github.com/brechtsanders/winlibs_mingw - but I would be interested to find out how!) but what happens is that random_bits always returns the same, "stP1kAlM". The immediate consequence is that on Linux the following small application produces different temporary files at each invocation: #include <stdlib.h> #include <stdio.h> #include <string.h> #include <unistd.h> char tmpl[100]; int main() { strncpy(tmpl, "stXXXXXX", 8); // create temp file int fd = mkstemp(tmpl); printf("%s\n", tmpl); //close and remove file immediately after close(fd); remove(tmpl); return 0; } while on Windows, when being compiled with mingw gcc it produces THE SAME OUTPUT for each invocation. I am not sure if gnulib is also used on Linux as well - but I am sure it is at least used by mingw gcc. Actually, this is the end of a long investigation I did regarding sporadic failures we had with ar.exe at our company. We're using gcc 10 on Windows and from time to time some builds would fail due to ar.exe ie. "ar.exe: could not create temporary file whilst writing archive: Permission denied". When studying the ar.exe process activity with procmon I saw that lots of "stP1kAlM" files were being created and removed. I traced it through binutils and then mkstemp. ar basically does the same as my small sample app above, it creates a temporary file to construct the *.lib contents then it copies its contents to the final *.lib file. When being invoked concurrently in the same folder (ie. to produce multiple libraries) race conditions might appear due to the fact the same filename is used. Therefore, I want to ask you how we can patch gnulib so the behaviour is similar between glibc and gnulib. Of course, we first need to investigate why there is no entropy to begin with ie. bug root cause. Regards, Mihai Sterpu
