http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-03-24
11:27:44 UTC ---
(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.
> > 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.
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);
> > 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!
In any case, if you try your original example with current releases it doesn't
print '4'
