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.
