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

[Janne Blomqvist <blomqvist dot janne at gmail dot com>]

On Sat, Mar 12, 2011 at 17:21, FX <fxcoudert@gmail.com> wrote:
> 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?

A static variable which is modified introduces a race condition.
Secondly, you reset the count to 0 at the start of every loop which
makes the static thing superfluous?

One solution would be to declare count as an automatic int and set it
to 0 outside the do-while loop; this implies there will be an extra
trip through the loop once 26 temp files are in use, two extra trips
once 2*26 temp files are used etc. but I don't think this is worth
worrying about.

If that is not acceptable, one can manipulate the static counter with
__sync_fetch_and_add (with #ifdef HAVE_SYNC_FETCH_AND_ADD) or
protected by a mutex.

> PS: Please note that, on modern targets providing the POSIX mkstemp(), this code is not used at all.
>
>



-- 
Janne Blomqvist