2016-12-16 19:46 GMT+01:00 Pedro Alves <pal...@redhat.com>: >>>> And in particular: How do the current uses of >>>> std::string in GCC deal with this problem? (Do they?) >>> >>> Doesn't look like they do. >> >> Huh, that's a problem then, isn't it? > > Right. The easiest way to trigger it I think is if something > computes some size incorrectly, and calls for example string::reserve(-1) > or string::resize(-1) by mistake (likewise for std::vector, etc.). > malloc will fail, new will throw bad_alloc, and GCC will abort and > maybe generate a core dump, instead of gracefully printing > something like: > > cc1: out of memory allocating NNNNNNNN bytes ... > > and existing with error status.
So, it seems like it would be a good idea to follow your suggestion from PR 78822: > You can replace the global operator new/new[] to call xmalloc instead of > malloc. > Then memory allocation by std::string etc. ends up in xmalloc -> > xmalloc_failed. > That's what I did for GDB: > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/common/new-op.c;h=c67239cbe87c1f7e22e234a1a2cc2920f9ed22a4;hb=HEAD I'm certainly not the right person to implement this in GCC, though (and I'll probably discard my idea of using std::string for PR 78822 and follow the alternative implementation from comment 14). But I think that, given the amount of STL containers already used in GCC, it should definitely be clarified whether this is necessary ... Cheers, Janus
