aboutsummaryrefslogtreecommitdiff
path: root/gcc
diff options
context:
space:
mode:
authorJoel Brobecker <brobecker@adacore.com>2022-06-23 13:12:12 +0100
committerJonathan Wakely <jwakely@redhat.com>2022-06-27 11:08:17 +0100
commit30a8f67295f4123fd7cb740c6927592bccb0e7c5 (patch)
tree3be8d6b7a927c1350ac302966279bc124014b767 /gcc
parenta364488f7a70ebf6c1fd59fed9f6a8a477591087 (diff)
downloadgcc-30a8f67295f4123fd7cb740c6927592bccb0e7c5.zip
gcc-30a8f67295f4123fd7cb740c6927592bccb0e7c5.tar.gz
gcc-30a8f67295f4123fd7cb740c6927592bccb0e7c5.tar.bz2
libstdc++: testsuite: avoid predicable mkstemp
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/copy_file.cc 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. Co-authored-by: Jonathan Wakely <jwakely@redhat.com> libstdc++-v3/ChangeLog: * testsuite/util/testsuite_fs.h (__gnu_test::nonexistent_path): Always include a counter in the filename returned.
Diffstat (limited to 'gcc')
0 files changed, 0 insertions, 0 deletions