This is the mail archive of the
mailing list for the GDB project.
Re: make_cleanup_func elimination
- To: Jim Kingdon <kingdon at redhat dot com>
- Subject: Re: make_cleanup_func elimination
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Tue, 21 Mar 2000 00:36:42 +1100
- CC: gdb-patches at sourceware dot cygnus dot com
- Organization: Cygnus Solutions
- References: <200003192252.RAA14902@devserv.devel.redhat.com>
Jim Kingdon wrote:
> This patch takes the advice of the comments in defs.h.
> I did try a few testsuite runs without obvious disasters, but I needed
> to re-do them to get completely good numbers, and I haven't been
> getting around to that. So sending the patch in now seemed better
> than just letting it sit around without telling anyone.
> 2000-03-13 Jim Kingdon <firstname.lastname@example.org>
> Fix dubious assumptions about sizes of host pointers and ints and
> such in calling make_cleanup:
> * coffread.c, solib.c, dbxread.c, mipsread.c, os9kread.c,
> elfread.c, nlmread.c, somread.c, xcoffread.c, ax-gdb.c,
> tracepoint.c, dwarf2read.c, command.c, eval.c, top.c, event-top.c,
> top.h, breakpoint.h, breakpoint.c, infrun.c, infcmd.c, varobj.c,
> parse.c, stack.c, printcmd.c, symfile.c, symtab.c, thread.c,
> typeprint.c, valops.c, procfs.c, hp-psymtab-read.c, hppa-tdep.c,
> sparcl-tdep.c, remote-udi.c, procfs.c, remote-e7000.c: Don't cast
> argument to make_cleanup. Instead give the function we pass the
> right argument type one way or another. In various cases change
> argument types or add wrapper functions. In the case of bfd_close
> (many places), close (procfs.c), closedir (procfs.c), chdir
> (top.c), fclose (top.c), add error handling.
> * defs.h (make_cleanup_func): Remove.
(Yes, this will be hard to take seriously given that I botched the
The main thing to note is that the reason I didn't rush back and fix the
make_cleanup_func botch (ok so JasonM helped me :-) was because, as far
as anyone knows (gcc people here), while the code is technically in
violation of ISO-C there isn't a mainstream platform on which the hack
will actually fail. Consequently, there is no pressure to apply a quick
fix and instead changes that improve the overall code are being sort.
This is why I've been slowly going through and adding functions like:
extern struct cleanup *make_cleanup_ui_file_delete (struct ui_file
rather than changing functions signatures:
-static void free_variable PARAMS ((struct varobj * var));
+static void free_variable (void *);
The original function was strongly typed. By changing it to void* that
type information is lost and the chance of incorrect use increased.
If you wan't to persue this then could I suggest breaking the patch down
into specific fixes and submitting each in turn, that way each
maintianer can merge it in. Alternativly, I can file it into my post
5.0 branch list (1) and I'll work through them.