This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: using C++ STL containers in GCC/gfortran source code

2016-12-16 19:46 GMT+01:00 Pedro Alves <>:
>>>> 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:

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 ...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]