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/
