The attached patch fixes half of PR 47439. On platform with weak or historical implementations of mktemp(), this function cannot generate more than 26 unique filenames for a given base. This happens in particular on Windows, and limits us to 26 scratch files open simultaneously.
The patch works around that by adding an almost unique prefix to the filename string, which has a period of 17576. Thus, the new implementation allows to generate 456976 unique filenames, which I deemed enough :) As the issue is not a regression, I don't think it's 4.6 material so, if approved, I will commit when 4.7 branches unless instructed to do otherwise. I'd also like feedback on the attached test: do we expect systems to fail because of limits not allowing them to open 30 files? Manually tested on i586-pc-mingw32, regtested on x86_64-linux by editing config.h to fake the absence of mkstemp(). OK for 4.7? PS: Please note that, on modern targets providing the POSIX mkstemp(), this code is not used at all.
mktemp.ChangeLog
Description: Binary data
mktemp.diff
Description: Binary data
scratch_1.f90
Description: Binary data
