| Message ID | ye6qy5fjcd5y.fsf@elbrus2.mtv.corp.google.com |
|---|---|
| State | New |
| Headers | show |
On Thu, Jan 24, 2013 at 1:23 AM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote: > This patch allows us to catch use of destructed strings. > > Google ref: b/5430313 > > Ok for google/gcc-4_7 and google/integration? OK. Diego.
On Wed, 23 Jan 2013, Paul Pluzhnikov wrote: > This patch allows us to catch use of destructed strings. Hello, while a number of the google debug patches are just cheaper versions (that don't break the ABI) of what libstdc++'s debug mode provides, this overwriting of classes on destruction is not as obviously redundant, and I wonder whether something like it (done consistently for many classes) could go to trunk... > Google ref: b/5430313 > > Ok for google/gcc-4_7 and google/integration? > > -- > Paul Pluzhnikov > > > > Index: libstdc++-v3/include/ext/sso_string_base.h > =================================================================== > --- libstdc++-v3/include/ext/sso_string_base.h (revision 195417) > +++ libstdc++-v3/include/ext/sso_string_base.h (working copy) > @@ -215,7 +215,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > const _Alloc& __a); > > ~__sso_string_base() > - { _M_dispose(); } > + { > + _M_dispose(); > +#ifdef __google_stl_debug_dangling_string > + __builtin_memset(this, 0xcd, sizeof(*this)); > +#endif > + } > > _CharT_alloc_type& > _M_get_allocator()
On 24 January 2013 19:03, Marc Glisse wrote: > On Wed, 23 Jan 2013, Paul Pluzhnikov wrote: > >> This patch allows us to catch use of destructed strings. > > > Hello, > > while a number of the google debug patches are just cheaper versions (that > don't break the ABI) of what libstdc++'s debug mode provides, this > overwriting of classes on destruction is not as obviously redundant, and I > wonder whether something like it (done consistently for many classes) could > go to trunk... Thanks for pointing this out, Marc. This does look like something that could be included in debug mode, but probably not until we're back in Stage 1. Please either put it in Bugzilla (and CC me) or if you're diligent enough to remember please email us again during Stage 1 :-) Googlers, please include the libstdc++ list on patches to the libstdc++ code, even if it's only to a google branch. I don't read gcc-patches but am still interested in the changes you make to the code on your branch.
On Thu, Jan 24, 2013 at 7:15 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > Googlers, please include the libstdc++ list on patches to the > libstdc++ code, even if it's only to a google branch. I don't read > gcc-patches but am still interested in the changes you make to the > code on your branch. Thanks Jonathan. We'll do. Diego.
On Thu, Jan 24, 2013 at 4:15 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > This does look like something that could be included in debug mode, > but probably not until we're back in Stage 1. Please either put it in > Bugzilla (and CC me) or if you're diligent enough to remember please > email us again during Stage 1 :-) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56109 > Googlers, please include the libstdc++ list on patches to the > libstdc++ code, even if it's only to a google branch. Will do. Sorry about that. Thanks,
Index: libstdc++-v3/include/ext/sso_string_base.h =================================================================== --- libstdc++-v3/include/ext/sso_string_base.h (revision 195417) +++ libstdc++-v3/include/ext/sso_string_base.h (working copy) @@ -215,7 +215,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION const _Alloc& __a); ~__sso_string_base() - { _M_dispose(); } + { + _M_dispose(); +#ifdef __google_stl_debug_dangling_string + __builtin_memset(this, 0xcd, sizeof(*this)); +#endif + } _CharT_alloc_type& _M_get_allocator()