This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: introduce scoped cleanups
- From: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Joel Brobecker <brobecker at adacore dot com>, gdb-patches at sourceware dot org
- Date: Fri, 31 May 2013 14:23:57 -0600
- 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>
Pedro> Seeing Tom's scope cleanups were already stack based and most of
Pedro> the way there, made me feel that it'd be a pity to be able to
Pedro> have stack-based cleanups, but then as soon as you need a real
Pedro> cleanup that does actual cleanup (as opposed to null_cleanup),
Pedro> you still need to get back to install a heap cleanup anyway.
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.
This approach would either have to still leave the special scoped
cleanup on the stack, at least when compiling with GCC (and perhaps only
if in "development=true" mode); or we would need to come up with some
extra hack to make this work properly with obstack allocation.
Tom