https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69608
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-05-02
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #0)
> As far as I can see, the C++ standard doesn't prevent the copying of
> strstreambuf objects. With the resolution of issue 421 these copies should
> have (almost) well-defined semantics. But the following program fails to
> compile with the latest libstdc++.
>
> That said, I'm not sure it's a good idea for the standard to require
> implementations to accept the program. If it did, it seems that the two
> copies would share the same underlying character buffer (courtesy of issue
> 421). Accessing the buffer in the copy would be undefined after the copied
> strstreambuf object was destroyed.
Simply removing the private copy constructor and copy assignment operator
allows the program to compile, but with undefined behaviour:
==16384== Memcheck, a memory error detector
==16384== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==16384== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==16384== Command: ./a.out
==16384==
==16384== Invalid free() / delete / delete[] / realloc()
==16384== at 0x4C2F6B8: operator delete[](void*) (vg_replace_malloc.c:621)
==16384== by 0x4EE0D08: std::strstreambuf::~strstreambuf()
(strstream.cc:117)
==16384== by 0x400773: main (ss.cc:5)
==16384== Address 0x5ad0cd0 is 0 bytes inside a block of size 32 free'd
==16384== at 0x4C2F6B8: operator delete[](void*) (vg_replace_malloc.c:621)
==16384== by 0x4EE0D08: std::strstreambuf::~strstreambuf()
(strstream.cc:117)
==16384== by 0x400764: main (ss.cc:6)
==16384== Block was alloc'd at
==16384== at 0x4C2E8B7: operator new[](unsigned long)
(vg_replace_malloc.c:423)
==16384== by 0x4EE0C5C: std::strstreambuf::strstreambuf(long)
(strstream.cc:61)
==16384== by 0x400742: main (ss.cc:6)
==16384==
==16384==
==16384== HEAP SUMMARY:
==16384== in use at exit: 16 bytes in 1 blocks
==16384== total heap usage: 3 allocs, 3 frees, 72,752 bytes allocated
==16384==
==16384== LEAK SUMMARY:
==16384== definitely lost: 16 bytes in 1 blocks
==16384== indirectly lost: 0 bytes in 0 blocks
==16384== possibly lost: 0 bytes in 0 blocks
==16384== still reachable: 0 bytes in 0 blocks
==16384== suppressed: 0 bytes in 0 blocks
==16384== Rerun with --leak-check=full to see details of leaked memory
==16384==
==16384== For counts of detected and suppressed errors, rerun with: -v
==16384== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> If this hasn't been discussed in LWG yet
> it might be worth bringing it up.
I'll do so.
> strstreambuf may be deprecated but the
> same concern applies to similar user-defined classes that publicly derive
> from basic_streambuf and expose an accsible copy ctor or assignment operator
> of their own.
User-defined classes are responsible for defining their own copy operations
correctly. The issue as I see it is that strstreambuf fails to do that. If
user-defined classes fail to do that it's the user's problem.
