From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: kevinb@cygnus.com Cc: taylor@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Sat, 03 Jun 2000 03:58:00 -0000 Message-id: <200006031058.GAA12885@indy.delorie.com> References: <200006021539.LAA25912@texas.cygnus.com> <1000602191042.ZM30936@ocotillo.lan> X-SW-Source: 2000-06/msg00030.html > Date: Fri, 2 Jun 2000 12:10:42 -0700 > From: Kevin Buettner > > > 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.