[libgfortran, patch] More than 26 temporary files with weak mktemp()

[FX]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mktemp.ChangeLog
Type: application/octet-stream
Size: 190 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20110312/7de1fd3a/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mktemp.diff
Type: application/octet-stream
Size: 1203 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20110312/7de1fd3a/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scratch_1.f90
Type: application/octet-stream
Size: 172 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20110312/7de1fd3a/attachment-0002.obj>