This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Proposal: convert function definitions to prototyped form
- To: kevinb at cygnus dot com
- Subject: Re: Proposal: convert function definitions to prototyped form
- From: Eli Zaretskii <eliz at delorie dot com>
- Date: Sat, 3 Jun 2000 06:58:39 -0400 (EDT)
- CC: taylor at cygnus dot com, gdb at sourceware dot cygnus dot com
- References: <200006021539.LAA25912@texas.cygnus.com> <1000602191042.ZM30936@ocotillo.lan>
- Reply-to: Eli Zaretskii <eliz at is dot elta dot co dot il>
> Date: Fri, 2 Jun 2000 12:10:42 -0700
> From: Kevin Buettner <kevinb@cygnus.com>
>
> > 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?
I think the real problem is not the number of developers, but the
number of different configurations, and also different data types and
functions concealed behind macros. `protoize' needs everything to be
explicit, so it is not easy to run it on multi-platform project that
uses macros to hide system dependencies (since you want the same
macros back in the reformatted sources).
This is a disadvantage of `protoize'. Its significant advantage is
that its output is *always* correct, because it takes the info ``from
the horse's mouth'': the compiler itself. In contrast, a script is
simply a text-processing tool: it really doesn't understand the
semantics of the source. In fact, it doesn't really understand the
syntax very well.
So with a script, we will always need a verification tool that can be
trusted to find any potential bugs introduced by reformatting.
> > 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
> > files...
>
> Good idea. I'll have to see what gcc does to compare object files.
> (I don't think a simple cmp works for ELF files.)
Comparing object files generally doesn't work. COFF (at least the
variety used by DJGPP) is another case: if I compile the same source
twice in a row, I get different object files (IIRC, the time stamp is
recorded inside).
One method I can suggest is to compile the source without
optimizations, then run "objdump --disassemble" and compare the output
of `objdump' for the two source files (original and reformatted). (I
suggest to disable optimizations because it's possible that ANSI
source allows the compiler to produce more optimal code that the K&R
source.)
Note that, since you need to compile the source to make sure
reformatting didn't screw up anything, you essentially get the same
problems you had with `protoize', albeit through the back door: you
need to build for all supported configurations to make sure nothing's
broken.