This is the mail archive of the
mailing list for the GDB project.
Re: Proposal: convert function definitions to prototyped form
- To: Kevin Buettner <kevinb at cygnus dot com>
- Subject: Re: Proposal: convert function definitions to prototyped form
- From: David Taylor <taylor at cygnus dot com>
- Date: Fri, 02 Jun 2000 11:39:48 -0400
- cc: gdb at sourceware dot cygnus dot com
Date: Fri, 2 Jun 2000 00:50:19 -0700
From: Kevin Buettner <firstname.lastname@example.org>
2) ``protoize'' fails to convert functions disabled by ifdefs for
the given platform. OTOH, on some other platform(s), these
functions might not be disabled and would be converted. E.g,
in breakpoint.c, on my GNU/Linux/x86 machine, protoize failed
to convert create_longjmp_breakpoint() which is protected by an
With any solution, either you're going to have to check the results or
you're going to have to hand convert some of the stuff. It's a
tradeoff. From what you say below, your script also requires some
later hand conversions.
Does your script produce substantially less that needs to be hand
3) ``protoize'' screws up on PTR types. E.g, in breakpoint.c, it
cover_target_enable_exception_callback (__builtin_va_list arg)
I consider this to be a more serious problem than the other complaints
4) ``protoize'' does not reformat long argument lists. The lists
end up entirely contained on one line.
So... adopt the same solution for it that you chose to adopt for your
script -- run indent on the output!
For more information on protoize, see the "Running protoize" page:
and the "Caveats of using protoize" page:
I've used protoize before with good results. It was a fairly
substantial project, though not as big as gdb.
Two of my goals in creating the scripts for the PARAMS purging
activities was that the scripts should be 1) easy to invoke and 2)
require no hand editing of the output when done. I.e, you shouldn't
have to edit any of the files that these scripts touch in order to fix
I trust that "3)" is:
"be conservative; not convert something if it can't be sure
of getting it right".
I'd much rather hand convert more of the code than have it make a
subtle but incorrect change.
errors so that you can build again. OTOH, the script may leave
certain portions of the file alone that could possibly have be
converted had the script been a little smarter. The things that the
script fails to convert *will* have to be fixed later on (in order to
complete the cleanup activity), either by another script, or by hand.
For the PARAMS purging activity, I have spent a fair amount of time
examining the diffs to make sure that this is indeed the case. (And
I intend to do the same for the activity in this proposal.)
The reason that it is so important to avoid any hand edits is that we
want people who have local repositories or checked out source trees to
be able to run these conversion scripts against them so that merges
will be less painful. (Even easy.)
With that said, keeping in mind the problems I noted above, I conclude
that ``protoize'' is not the appropriate tool for us to use to convert
function definitions in the gdb sources to their prototyped form.
I only consider 3) -- screwing up on PTR types -- to be serious; the
others seem minor enough.
Finally, I should note that I've done a test build on GNU/Linux/x86
and had no build problems, nor did I see any regressions when I ran
The fix-decls script is below. I'd be interested in finding out if
anyone else has a favorite script for doing this sort of thing. Other
comments welcome too.
I'd be tempted to do a build before running your script; stash away the
object files; run the script; do another build; compare the object
I consider the lack of (prototyped) function declarations to be more
serious "problem" than the use of old style function definitions in
old code. I'd like to see:
. declarations near the top of every file (i.e., before the first
function definition) for every static function in the file.
. a declaration in an included header file for every non static
function definition and for every non static function used.
. changes to the default configuration to "encourage" developers to
include the above declarations.