Hi,
Sterpu Mihai wrote:
> 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.
We need to be careful to not confuse the various implementations of mkstemp.
There are:
(1) mkstemp defined by mingw,
(2) mkstemp defined by gnulib on mingw,
(3) mkstemp defined by glibc on Linux,
(4) mkstemp defined by gnulib on Linux.
The one in (3) is a high-quality implementation.
(1) When I take your program and compile it on mingw, I get
$ $CC foo.c
$ ./a.exe
stP1kAlm
$ ./a.exe
stP1kAlm
So, that's a low-quality implementation.
Now, for (2) and (4), let's create a gnulib testdir:
./gnulib-tool --create-testdir --dir=../testdir4 --single-configure mkstemp
(4) When I compile this testdir on Linux with glibc, I see that
- config.status has
S["HAVE_MKSTEMP"]="1"
S["REPLACE_MKSTEMP"]="0"
- in the gllib/ directory, there is no mkstemp.o file.
This means that gnulib has decided that the glibc function is working right
and therefore does not need an override.
(2) When I
- compile this testdir for mingw,
- change foo.c for use with gnulib, i.e. add a '#include <config.h>' line
as first line,
- compile foo.c against gnulib:
$ $CC foo.c -Itestdir4/build-mingw64 -Itestdir4/build-mingw64/gllib \
testdir4/build-mingw64/gllib/libgnu.a
$ ./a.exe
stFfT70P
$ ./a.exe
stRqF8Lh
$ ./a.exe
stCo4Pvn
I get different file names each time. So, that's a high-quality
implementation.
Conclusions:
* The binaries that you ran are using the mingw mkstemp, not the gnulib
mkstemp.
* If they were using the gnulib mkstemp, you would not be seeing the problem
that you are seeing.
* Your source code analysis of tempname.c is incorrect. Despite
random_value v = 0;
randomness comes in through the first call
random_bits (&v, v)
which invokes getrandom, which relies on the Windows functions
BCryptGenRandom and CryptGenRandom.
Bruno
