On Tuesday 18 November 2025 21:09:47 Martin Storsjö wrote:
> On Tue, 18 Nov 2025, Pali Rohár wrote:
>
> > On Tuesday 18 November 2025 20:53:12 Martin Storsjö wrote:
> > > On Tue, 18 Nov 2025, Pali Rohár wrote:
> > >
> > > > > presume this is new in msvcr110/UCRT or newer? As the behaviour you
> > > > > describe
> > > > > of tmpnam() is that it only generates a string "\<random>", right?
> > > >
> > > > Yes, in my tests I saw only "\<random>" in buffer returned by tmpnam().
> > > >
> > > > > As the
> > > > > old tmpnam() doesn't see the full string, only the name subset, does
> > > > > it do
> > > > > anything to check that the returned names are unique already? As the
> > > > > current
> > > > > docs say "Each of these functions returns the name of a file that
> > > > > doesn't
> > > > > currently exist. " - but that can't be proven if it doesn't even see
> > > > > the
> > > > > full path?
> > > >
> > > > Seems that the tmpnam() generates fixed string pattern followed by some
> > > > number which is increased by every call.
> > >
> > > Ok, so if it is incremented after each call, then we should be good here.
> > >
> > > > But because tmpnam() function does not create a file (it just generates
> > > > filename), there can be still a race condition between tmpnam() and
> > > > creat() calls. For example another process could generate by its own
> > > > same filename and create file earlier.
> > >
> > > Yes, I know that we must check that we actually get an unique file opened
> > > here.
> > >
> > > > > The patch looks ok, if old versions of tmpnam() behave in the way of
> > > > > just
> > > > > returning a random string and not trying to check if the file is
> > > > > unique (ok,
> > > > > we can't know what it does internally) without a full path, just
> > > > > starting
> > > > > with a backslash.
> > > >
> > > > For our mingw-w64 tmpfile() implementation it does not matter if the
> > > > tmpnam() returned existing or non-existing filename in the root C:\.
> > >
> > > It _could_ be an issue, depending on the implementation of tmpfile(). If
> > > tmpfile returns an entirely random name, or an always incrementing number
> > > (with a counter that is shared between calls), then we are good.
> > >
> > > But consider the following implementation of tmpnam():
> > >
> > > int idx = 0;
> > > while (true) {
> > > sprintf(buf, "\tmp%03d", idx);
> > > if (!exists(buf))
> > > return buf; // Found a non-existing filename
> > > idx++;
> > > }
> > >
> > > Then we would have a problem! Because tmpnam() could each time return a
> > > filename like "\tmp000", because it internally checks that "\tmp000" does
> > > not exist, and only proceeds to "tmp001" if "\tmp000" exists. But in our
> > > case, after tmpnam returns that, we check "<GetTempPath>\tmp000" which
> > > does
> > > exist, so we call tmpnam() again, and again and essentially hang there.
> > >
> > > But if you say that we don't get this behaviour, then I think we're safe.
> > >
> > > // Martin
> >
> > Now I see what you mean. I run tmpnam() in the loop without creating the
> > file and I always got different filename from tmpnam(). So I think that
> > we should not hit the above issue.
> >
> > Also in the documentation pages linked in previous email is written:
> >
> > msvcrt40, msvcrt (5) and msvcrt (6):
> > "The function generates unique filenames for up to TMP_MAX calls."
> >
> > msvcr70-msvcr120:
> > "The name generated by tmpnam consists of a program-generated file name
> > and, after the first call to tmpnam, a file extension of sequential
> > numbers in base 32 (.1-.vvu, when TMP_MAX in STDIO.H is 32,767)."
> >
> > So it matches my observation.
>
> Ok, great! Then this patch should be fine - I'll try to push it soon.
>
> // Martin
Ok, thanks! Could you also the sourceforge bug report? Because I cannot
do it (or I do not know how).
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
