This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [libgfortran, patch] More than 26 temporary files with weak mktemp()
- From: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- To: FX <fxcoudert at gmail dot com>
- Cc: gfortran List <fortran at gcc dot gnu dot org>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 14 Mar 2011 12:18:16 +0200
- Subject: Re: [libgfortran, patch] More than 26 temporary files with weak mktemp()
- References: <E785758F-47C6-4B1D-B8F3-EA2FAAF62EDD@gmail.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