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: [RFC] First 3.5 project: don't assign _S_terminal in string::c_str()

From: Paolo Carlini <pcarlini at unitus dot it>
To: Nathan Myers <ncm-nospam at cantrip dot org>
Cc: libstdc++ <libstdc++ at gcc dot gnu dot org>
Date: Sun, 18 Jan 2004 12:14:56 +0100
Subject: Re: [RFC] First 3.5 project: don't assign _S_terminal in string::c_str()
References: <40093A70.3050009@suse.de> <20040118045615.GB24746@tofu.dreamhost.com>

Nathan Myers wrote:

I say go for it. c_str() is used frequently enough that would
certainly hear about it quickly if it got broken; and if it did,
that would reveal latent bugs like the one in _M_clone. As it
is, the assignment only interferes with us finding those bugs.


Agreed! The complete set of changes for mainline (would be 3.5) are
already in.

Is 3.4 frozen and branched, now? I missed the announcement.
Seems to me the _M_clone bug should be fixed in 3.4, too.

Ok, the _M_clone fix will go shortly into 3_4 too.

Thanks!
Paolo.

References:
- [RFC] First 3.5 project: don't assign _S_terminal in string::c_str()
  - From: Paolo Carlini
- Re: [RFC] First 3.5 project: don't assign _S_terminal in string::c_str()
  - From: Nathan Myers

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