This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: introduce scoped cleanups
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Pedro Alves <palves at redhat dot com>, gdb-patches at sourceware dot org
- Date: Mon, 3 Jun 2013 10:07:16 +0400
- Subject: Re: RFC: introduce scoped cleanups
- References: <87li7ohtiu dot fsf at fleche dot redhat dot com> <87ppw8qlgl dot fsf at fleche dot redhat dot com> <20130531061135 dot GA12363 at adacore dot com> <87obbrp2hg dot fsf at fleche dot redhat dot com> <51A8CC81 dot 9070509 at redhat dot com> <8738t2q4o2 dot fsf at fleche dot redhat dot com>
> My one concern about this code is that, if a stack cleanup should be
> leaked, then any future cleanup operation will refer to invalid memory.
>
> Right now, cleanup failures like this are a memory leak with the
> possibility of wrong behavior -- but the new way seems more directly
> fatal.
>
> Another option would be to allocate cleanups on an obstack.
> This would often be efficient and would avoid the above problem.
A very valid concern, IMO! I've never seen heap allocation as
a reason for concern with respect to performance, and thus have
never hesitated calling malloc. The only reason I have prefered
alloca whenever possible is that it allows me to be lazy :-)!
But this made me realize something: Why would someone want to do
stack-cleanups instead of just calling alloca directly? Since
alloca is basically a call-and-forget, what's the advantage of
going through a stack-based cleanup?
Regardless of the above, I like the idea of performing the cleanups
on an obstack; fast and yet a little more resilient to programming
errors. Not sure if that would be something easy to implement or not,
though.
--
Joel