When you remove code, it's easy to forget function declarations.
That made me wonder how many orphan prototypes there are that refer
to functions that no longer exist.
There is an intriguing gcc option. I'll quote its description in
full, from the info manual:
`-aux-info FILENAME'
Output to the given filename prototyped declarations for all
functions declared and/or defined in a translation unit, including
those in header files. This option is silently ignored in any
language other than C.
Besides declarations, the file indicates, in comments, the origin
of each declaration (source file and line), whether the
declaration was implicit, prototyped or unprototyped (`I', `N' for
new or `O' for old, respectively, in the first character after the
line number and the colon), and whether it came from a declaration
or a definition (`C' or `F', respectively, in the following
character). In the case of function definitions, a K&R-style list
of arguments followed by their declarations is also provided,
inside comments, after the declaration.
I built a kernel with -aux-info. (After make config, edit Makefile
and add something like -aux-info ${@:.o=.X} to NORMAL_C.)
That produces a lot of raw data that can be further processed with
the usual Unix text tools.
To find orphan prototypes, I tried two approaches:
(1) Check the -aux-info output for functions that are declared but
not defined.
(2) Compare the functions that are declared in the -aux-info output
with the kernel symbol table (nm -g bsd).
I then picked a handful of suspect function names turned up by
either scheme and grepped the tree. Unfortunately, both approaches
are subject to false positives. (1) spits out functions that are
actually implemented in assembly. (2) runs into functions that are
defined, but don't show up in the symbol table because they are
inlined. Both approaches turn up function definitions that are
behind various #ifdef guards. There are probably more problems, but
I quickly lost interest when it became obvious that the results
were dominated by false positives.
No, this is not a success story.
Something else fell out of the -aux-info run. We still have tons
of function definitions that aren't ANSI-fied. I wonder whether
it would be worth to clean that up in one final push.
And another pattern showed up:
int func();
int func()
{
...
}
Neither of these is ANSI style. If a function doesn't take parameters,
the parameter list needs to say "void". Looks like somebody forgot
about this--e.g. when ansifying the network code. I thought about
cleaning these up, but then there's little point when we still have
so much unansified code anyway.
Also, as useful as -aux-info is, it requires actual compiling, so
it won't help with MD code for other architectures or drivers that
aren't configured in the kernel.
--
Christian "naddy" Weisgerber [email protected]
