using C++ STL containers in GCC/gfortran source code
Janus Weil
janus@gcc.gnu.org
Sat Dec 17 10:58:00 GMT 2016
2016-12-16 19:46 GMT+01:00 Pedro Alves <palves@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
More information about the Gcc
mailing list