This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] libstdc++/8466


On Tue, Nov 05, 2002 at 11:35:34PM +0100, Paolo Carlini wrote:

> the bug is due to the Copy On Write nature of v3 string: in
> varios members of basic_stringbuf and basic_(i,o)stringstream
> a string is simply considered as a buffer of chars.
> Therefore
> 
>      void
>      str(const __string_type& __s)
>      {
>        _M_string = __s;
>        _M_stringbuf_init(_M_mode);
>      }
> 
> which produces an _M_string having the Rep shared with __s
> is very dangerous, since, as soon as the buffer (the Rep)
> is directly modified, the original __s ends up being clobbered!

Could this be done safely if basic_stringbuf could tell the Rep it was
being modified, so a copy would be made when the buffer is directly
modified?
If basic_stringbuf can modify the Rep directly, shouldn't it do so safely,
rather than trying to ensure that the string it modifies is never shared?
Otherwise similar bugs could be introduced in future if someone is unaware
that basic_stringbuf modifies the buffer directly.

> I have fixed this with a "low-level assignment" of __s
> to _M_string:
> 
>      void
>      str(const __string_type& __s)
>      {   
>        _M_string.assign(__s.c_str(), __s.size());

Could this be

        _M_string.assign(__s.data(), __s.size());

to avoid assigning the unnecessary NULL-terminator?

>        _M_stringbuf_init(_M_mode);
>      }

jon


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]