public inbox for
 help / color / mirror / Atom feed
From: Alexandre Oliva <>
To: Jonathan Wakely <>
Cc: gcc Patches <>,
	"libstdc++" <>
Subject: Re: [PATCH] libstdc++: testsuite: avoid predictable mkstemp
Date: Thu, 23 Jun 2022 08:39:10 -0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Jonathan Wakely's message of "Wed, 22 Jun 2022 10:16:40 +0100")

On Jun 22, 2022, Jonathan Wakely <> wrote:

> On Wed, 22 Jun 2022 at 07:05, Alexandre Oliva via Libstdc++
> <> wrote:

>> It was prompted by a target system with a non-random implementation of
>> mkstemp, that returns a predictable sequence of filenames and selects
>> the first one that isn't already taken.

> OK

And here's the patch that enabled me to stop worrying about the above.
Regstrapped on x86_64-linux-gnu, also tested with a cross to
aarch64-rtems6.  Ok to install?

__gnu_test::nonexistent_path: Always include counter in filename returned

From: Joel Brobecker <>

We have noticed that, on RTEMS, a small number of testscases are
failing because two calls to this method return the same filename.
This happens for instance in 27_io/filesystem/operations/
where it does:

  auto from = __gnu_test::nonexistent_path();
  auto to = __gnu_test::nonexistent_path();

We tracked this issue down to the fact that the implementation of
mkstemp on that system appears to use a very predictable algorithm
for chosing the name of the temporary file, where the same filename
appears to be tried in the same order, regardless of past calls.
So, as long as the file gets deleted after a call to mkstemp (something
we do here in our nonexistent_path method), the next call to mkstemps
ends up returning the same filename, causing the collision we se above.

This commit enhances the __gnu_test::nonexistent_path method to
introduce in the filename being returned a counter which gets
incremented at every call of this method.


	* testsuite/util/testsuite_fs.h (__gnu_test::nonexistent_path):
	Always include a counter in the filename returned.
 libstdc++-v3/testsuite/util/testsuite_fs.h |   31 ++++++++++++++++++++++++----
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/testsuite/util/testsuite_fs.h b/libstdc++-v3/testsuite/util/testsuite_fs.h
index 037d9ffc0f429..206ea67779003 100644
--- a/libstdc++-v3/testsuite/util/testsuite_fs.h
+++ b/libstdc++-v3/testsuite/util/testsuite_fs.h
@@ -38,9 +38,9 @@ namespace test_fs = std::experimental::filesystem;
 #if defined(_GNU_SOURCE) || _XOPEN_SOURCE >= 500 || _POSIX_C_SOURCE >= 200112L
 #include <stdlib.h> // mkstemp
-#include <random>   // std::random_device
+#include <cstring> // strcpy
+#include <random>   // std::random_device
 #if defined(__MINGW32__) || defined(__MINGW64__) \
   || !defined (_GLIBCXX_HAVE_SYMLINK)
@@ -125,8 +125,32 @@ namespace __gnu_test
       file.erase(0, pos+1);
     test_fs::path p;
+    // A counter, starting from a random value, to be included as part
+    // of the filename being returned, and incremented each time
+    // this method is used.  It allows us to ensure that two calls
+    // to this method can never return the same filename, something
+    // testcases do when they need multiple non-existent filenames
+    // for their purposes.
+    static unsigned counter = std::random_device{}();
 #if defined(_GNU_SOURCE) || _XOPEN_SOURCE >= 500 || _POSIX_C_SOURCE >= 200112L
-    char tmp[] = "filesystem-test.XXXXXX";
+    // Use mkstemp to determine the name of a file which does not exist yet.
+    //
+    // Note that we have seen on some systems (such as RTEMS, for instance)
+    // that mkstemp behaves very predictably, causing it to always try
+    // the same sequence of file names.  In other words, if we call mkstemp
+    // with a pattern, delete the file it created (which is what we do, here),
+    // and call mkstemp with the same pattern again, it returns the same
+    // filename once more.  While most implementations introduce a degree
+    // of randomness, it is not mandated by the standard, and this is why
+    // we include a counter in the template passed to mkstemp.
+    std::string mkstemp_template ("filesystem-test.");
+    mkstemp_template.append(std::to_string (counter++));
+    mkstemp_template.append(".XXXXXX");
+    char tmp[mkstemp_template.length() + 1];
+    std::strcpy (tmp, mkstemp_template.c_str());
     int fd = ::mkstemp(tmp);
     if (fd == -1)
       throw test_fs::filesystem_error("mkstemp failed",
@@ -141,7 +165,6 @@ namespace __gnu_test
     if (file.length() > 64)
     char buf[128];
-    static unsigned counter = std::random_device{}();
     std::snprintf(buf, 128,

Alexandre Oliva, happy hacker      
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <>

  reply	other threads:[~2022-06-23 11:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-22  6:04 Alexandre Oliva
2022-06-22  9:16 ` Jonathan Wakely
2022-06-23 11:39   ` Alexandre Oliva [this message]
2022-06-23 16:36     ` Jonathan Wakely
2022-06-27  9:31       ` Alexandre Oliva
2022-06-27 10:18         ` Jonathan Wakely
2022-07-05  9:10         ` Alexandre Oliva
2022-07-05  9:16           ` Jonathan Wakely
2022-07-05 17:45             ` Alexandre Oliva
2022-07-05 18:02               ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).