Hello!
Thank you, as always, for the great work that you do on libstdc++. The
inout_ptr implementation properly handles the issue raised in LWG 3897
but it seems like having an explicit test might be a good idea.
I hope that this helps!
Will
-- >8 --
Add a test to verify that the implementation of inout_ptr is not
vulnerable to LWG Issue 3897.
libstdc++-v3/ChangeLog:
* testsuite/20_util/smartptr.adapt/inout_ptr/3.cc: New test
for LWG Issue 3897.
Signed-off-by: Will Hawkins <hawki...@obs.cr>
---
.../20_util/smartptr.adapt/inout_ptr/3.cc | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 libstdc++-v3/testsuite/20_util/smartptr.adapt/inout_ptr/3.cc
diff --git a/libstdc++-v3/testsuite/20_util/smartptr.adapt/inout_ptr/3.cc
b/libstdc++-v3/testsuite/20_util/smartptr.adapt/inout_ptr/3.cc
new file mode 100644
index 00000000000..f9114dc57b5
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/smartptr.adapt/inout_ptr/3.cc
@@ -0,0 +1,17 @@
+// { dg-do run { target c++23 } }
+
+#include <memory>
+#include <testsuite_hooks.h>
+
+// C++23 [inout.ptr.t] Class template inout_ptr_t
+// Verify that implementation handles LWG Issue 3897
+void nuller(int **p) {
+ *p = nullptr;
+}
+
+int main(int, char **) {
+ int *i = new int{5};
+ nuller(std::inout_ptr(i));
+
+ VERIFY(i == nullptr);
+}
--
2.41.0
