On 2024-10-04 07:52, Jonathan Wakely wrote:
This doesn't really belong in our testsuite, because the sole purpose of
the new test is to find bugs in the Glibc wrappers (like the one linked
below). But maybe it's a kindness to do it in our testsuite, because we
already have this test in place, and one Glibc bug was already found
thanks to Sam running the existing test with _FORTIFY_SOURCE defined.
Should we do this?
-- >8 --
Add a new testcase that repeats 17_intro/names.cc but with
_FORTIFY_SOURCE defined, to find problems in Glibc fortify wrappers like
https://sourceware.org/bugzilla/show_bug.cgi?id=32052 (which is fixed
now).
libstdc++-v3/ChangeLog:
PR libstdc++/116210
* testsuite/17_intro/names.cc (sz): Undef for versions of Glibc
that use it in the fortify wrappers.
* testsuite/17_intro/names_fortify.cc: New test.
---
libstdc++-v3/testsuite/17_intro/names.cc | 7 +++++++
libstdc++-v3/testsuite/17_intro/names_fortify.cc | 6 ++++++
2 files changed, 13 insertions(+)
create mode 100644 libstdc++-v3/testsuite/17_intro/names_fortify.cc
diff --git a/libstdc++-v3/testsuite/17_intro/names.cc
b/libstdc++-v3/testsuite/17_intro/names.cc
index 6b9a3639aad..bbf45b93dee 100644
--- a/libstdc++-v3/testsuite/17_intro/names.cc
+++ b/libstdc++-v3/testsuite/17_intro/names.cc
@@ -377,4 +377,11 @@
#undef y
#endif
+#if defined __GLIBC_PREREQ && defined _FORTIFY_SOURCE
+# if __GLIBC_PREREQ(2,35) && ! __GLIBC_PREREQ(2,41)
+// https://sourceware.org/bugzilla/show_bug.cgi?id=32052
+# undef sz
+# endif
+#endif
We've backported the fix to stable branches, so the version check isn't
really that reliable.
Sid
