This is the mail archive of the
mailing list for the GCC project.
Re: using C++ STL containers in GCC/gfortran source code
- From: Pedro Alves <palves at redhat dot com>
- To: Janus Weil <janus at gcc dot gnu dot org>
- Cc: "N.M. Maclaren" <nmm1 at cam dot ac dot uk>, gcc mailing list <gcc at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Sat, 17 Dec 2016 11:58:13 +0000
- Subject: Re: using C++ STL containers in GCC/gfortran source code
- Authentication-results: sourceware.org; auth=none
- References: <CAKwh3qgUN=mTFPg6Ew6Yk9RXgS3CttE7O3cGMQRcLKNqUOjBng@mail.gmail.com> <Prayer.firstname.lastname@example.org> <CAKwh3qhj-y5U9RrJ+nP45fGjRL2JbEKGKcVw4nsXMp-=h8jq-Q@mail.gmail.com> <email@example.com> <CAKwh3qiAGVjGVg0FKakEFmdmdJjPw=KQ7j0jYbB0qp2SPN__Aw@mail.gmail.com> <firstname.lastname@example.org> <CAKwh3qjjtxpA__+4dY6qhcjpjJdkKk_-=OSRu1QqntUAsL2L-Q@mail.gmail.com>
On 12/17/2016 10:58 AM, Janus Weil wrote:
> 2016-12-16 19:46 GMT+01:00 Pedro Alves <email@example.com>:
> 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 ...
TBC, STL containers are a red herring here, and a bit orthogonal.
The root issue is that any "new" expression that calls the
global (non-placement-new, non-class-specific) operator new/new
in GCC is "unprotected" and inconsistent with xmalloc already,
because the default operator new/new calls malloc.
I.e., "new" expressions are already "unprotected" in exactly the
same way as allocations inside STL containers.
Some classes have class-specific 'operator new' implementations (grep
for "operator new"), but seems to me many don't. E.g., grep
for " = new":
auto-profile.c: autofdo_source_profile *map = new autofdo_source_profile ();
auto-profile.c: function_instance *s = new function_instance (name, head_count);
auto-profile.c: afdo_string_table = new string_table ();
spellcheck.c: edit_distance_t *v0 = new edit_distance_t[len_s + 1];
new calls I think are more likely to cause trouble due to run-time variable
size, though non-array new calls can certainly fail too.
You should be able to trigger/see the issue by just hacking some:
char *p = new char [-1];
somewhere in the compiler. The compiler will likely crash with something
terminate called after throwing an instance of 'std::bad_alloc'
Aborted (core dumped)
... instead of the xmalloc_failed message.
and then compare with a "xmalloc (-1)" call.
TBC, replacing global operator new is perfectly defined/valid C++.
The overloads in question are specified as "replaceable". See: