On 29 August 2012 13:25, Michael Haubenwallner wrote: > > 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.
Bah, I did mess up my test, not correctly disabling the extern template instantiations in the library. If it works reliably on x86_64 then I think the patch is worth considering. I'm on holiday for a week, so maybe one of the other maintainers will deal with it first.
