[Bug libstdc++/48257] std::string::assign() corrupts std::string static data when called on emptyString1 using emptyString2.data()

["mohsinrzaidi at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257

--- Comment #13 from Mohsin <mohsinrzaidi at gmail dot com> 2011-03-25 05:48:21 UTC ---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > Two questions here:
> > > 
> > > 1. Is the behaviour undefined for __n < number of elements in __s?
> > >
> > 
> > Oops! I meant for __n >  number of elements in __s. 
> Yes!  The standard defines the behaviour of string::assign when s contains at
> least n elements. When that precondition isn't met the definition doesn't apply
> i.e. it's undefined.

Sorry for the confusion here Jon. I meant to ask if the specs define what the
behaviour should be if __s *does not* contain __n elements.

> > > 2. For cases undefined in the specs, do we take steps to ensure robustness? 
> Where possible, yes, that's what -D_GLIBCXX_DEBUG tries to do.  But in general
> it's not possible to verify that the supplied string meets the required length.
> Given a const char*, how do you tell if it points to an array of at least n
> chars?  You can't.

We could always look for the null-termination :) But like you say below, this
would add overhead and still not handle all cases.

> It would be possible to check that the supplied const char* is not the shared
> static "empty string" representation, but that would add overhead and still
> wouldn't prevent similar errors like:
>   string s("oops", 999);

Understood.

> > > I
> > > still cannot digest that a programmer error could corrupt std::string static
> > > memory.
> Really?  A sufficiently malicious/careless programmer can corrupt pretty much
> anything!

Hehe, understood.

> In any case, if you try your original example with current releases it doesn't
> print '4'

Great! I'll try that.

Thanks for bearing with my impetuous behaviour. I know it mustn't be easy
maintaining such a widely used code base.