On 08/28/2012 08:12 PM, Jonathan Wakely wrote: > On 28 August 2012 18:27, Michael Haubenwallner wrote: >>> >>> 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. > > Hmm, I tested it on x86_64-unknown-linux-gnu without getting a > segfault - but I might have messed up my test.
Using this patch on my x86_64 Gentoo Linux Desktop with gcc-4.7.1 does segfault as expected - when I make sure the correct libstdc++ is used at runtime, having the '_S_empty_rep_storage' symbol in the .rodata section rather than .bss. /haubi/
