On Sat, Mar 12, 2011 at 17:21, FX <fxcoud...@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