From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Taylor <taylor@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Proposal: convert function definitions to prototyped form
Date: Fri, 02 Jun 2000 13:11:00 -0000
Message-id: <200006022010.QAA25997@texas.cygnus.com>
X-SW-Source: 2000-06/msg00022.html

    Date: Fri, 2 Jun 2000 12:10:42 -0700
    From: Kevin Buettner <kevinb@cygnus.com>

    On Jun 2, 11:39am, David Taylor wrote:

    >       3) ``protoize'' screws up on PTR types.  E.g, in breakpoint.c, it
    >          converted
    > 
    >               static int
    >               cover_target_enable_exception_callback (arg)
    >                    PTR arg;
    > 
    >          to
    > 
    >               static int
    >               cover_target_enable_exception_callback (__builtin_va_list arg)
    > 
    > I consider this to be a more serious problem than the other complaints
    > you have.

    I think the setup issue is important too.  (I don't know if it's more
    serious though.)  As I mentioned in my first point (which is no longer
    quoted), you have to do a configure in the source directory above gdb

Sorry, I didn't consider it relevant to what I was replying to.

    in order to to properly run protoize or else it complains that it
    can't find certain header files.  Also, you need to make sure that the
    bfd header files are generated before you start.  None of these
    problems are insurmountable, but to do things safely with protoize,
    and in order to avoid polluting your sources with files that belong in
    a build tree, it would be necessary for a script using protoize to
    make a complete copy of the source tree somewhere else in order to do
    the work.

I don't consider the setup issue to be a big issue.  It requires some
time, but it doesn't require much human time.  Configure in the source
tree, then build.  Setup done.

During the commit phase, you don't commit anything that is new -- you
only commit files that existed prior to doing the configure.  No
separate tree needed.

    >       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!

    Granted.  A suitably imaginative script could identify just the lines
    that protoize touched and reformat those.  I don't think we want to
    run indent on entire files however, at least not for this activity.

Since Stan previously ran indent on all of the files, re-running it
*should* produce no change for stuff that hasn't changed.  Should
produce no change.  I'm not saying it won't.  If it changes its own
output when presented with it as input, I would consider that a bug.

    > I've used protoize before with good results.  It was a fairly
    > substantial project, though not as big as gdb.

    Okay.  Out of curiousity, did the project in question have a large
    number of active developers?  (This doesn't necessarily matter, but
    I think it's probably easier to manage this kind of thing when only
    a handful of developers are affected.)

It was at a former company.  There were a small number of active
developers all within the company.  The total project was around
200-250K lines of code.  There was a great deal less use of #if within
the sources than there is in GDB...

[...]
    I don't disagree, but I think that adding prototypes for everything
    should be a separate activity.  The question is whether it should
    occur before the activity covered by my proposal.  And if it should
    occur before, once again, we'll need to find a way to help automate
    the process because if we attempt to do it incrementally by hand
    over a period of time, it is likely that it'll never get done.

I agree that it should be a separate activity.

I think that your script is a good thing.  And due to the amount of
hand editing that appears to be necessary with protoize vs the amount
that appears to be necessary with your script, I think we should use
your script.

Ultimately, though, since you're doing the work, you get to select the
tool.  So long as it is fairly reliable and reasonably quick (quick in
terms of *your time*, not in terms of *elapsed time*), it doesn't
ultimately matter to me what tool you use.  (Which is not to say that
I am not interested in knowing what tool you use -- I am interested.)

Like I said, I think your script is a good thing.  And I look forward
to you using it to protoize the bulk of the GDB sources.

    Kevin

David