This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, libstdc++] Make empty std::string storage readonly
On 08/28/2012 06:46 PM, Jonathan Wakely wrote:
> On 28 August 2012 16:15, Michael Haubenwallner wrote:
>> Hi,
>>
>> in some old, large, originally C-written application (using gcc-4.2.4 still)
>> I did have to find a bug that boils down to something like this:
>>
>> std::string x;
>> strcpy( (char*) x.c_str(), "abc");
>>
>> Any subsequent empty std::string instance did contain "abc" instead of "",
>> which was the issue showing up to the user.
>>
>> My idea what could have helped out here was to make the empty string _Rep
>> object readonly (ie. const), to get a segmentation fault along the strcpy.
>
> Does it actually produce a segfault? I suppose it might on some
> platforms, but not all, so I'm not sure it's worth changing.
It does segfault here on (32bit each):
i686-pc-linux-gnu
ia64-hp-hpux11.31
i386-pc-solaris2.10
sparc-sun-solaris2.10
powerpc-ibm-aix5.3.0.0
powerpc-ibm-aix6.1.0.0
powerpc-ibm-aix7.1.0.0
It does not segfault here on:
hppa2.0n-hp-hpux11.31
i586-pc-interix5.2
i586-pc-winnt5.2 (using MSVC)
Maybe it could be made segfault on hppa2.0n-hp-hpux11.31 too using some linker flag,
but that's a deprecated platform anyway.
As long as the major development platform (Linux) does segfault, it feels worth
changing - especially as string.clear() to write the '\0' back again won't help
as quick'n dirty workaround since gcc-4.4.4 any more.
Also, a segfault is always better than random behaviour, even in production.
> (It seems easier to simply track down and shoot the programmer who
> thought it was OK to cast away const on the string! ;-)
I'm in doubt there isn't just one occurrence/developer with this bug...
Thank you!
/haubi/