This sounds good as far as the clean code perspective comes into play.

Any idea how much code will barf by adding the new options in?

I've been bitten in the past on systems with missing declarations so that's
definitly something we should be catching. 

Aren't redudant decls required in cases where some standards say you must
be able to only include X.h and it won't have any side effects through
include/reincluding other headers? i.e. the mutual independece part of the 
ANSI C spec for instance.

James


>
>I think it is a good idea to try to clean up our source tree from
>'scoped extern' declarations because they lead to unpredictable
>problems (see example below). In the past I thought that scoped
>extern declarations are cleaner, but I've changed my mind.
>
>In addition we seem to have a lot of duplicated declarations of
>functions in our include files that may lead to problems. A quick
>look finds:
>
>	sys_siglist, ftruncate, truncate, lseek, psignal, cuserid
>
>Finally the scoped extern declarations in the inline functions in
>signal.h are problematic (including errno.h before signal.h produces
>different code than including errno.h after signal.h)
>
>Do you think that it is worth it to add:
>
>    -Wmissing-declarations -Wredundant-decls -Wnested-externs
>
>to CFLAGS and cleanup the source tree? XFree86 has done so for their
>4.0 tree.
>
>I propose to add
>#ifndef __NAME_DECLARED
>#define __NAME_DECLARED
>int declare();
>#endif
>
>around the functions to avoid breakage.
>
>christos
>
>
>% cat zap1.c
>void zap() {
>}
>% cat zap2.c
>int zap;
>% cat main.c
>void foo() {
>	extern int zap;
>}
>void bar() {
>	extern void zap();
>	zap();
>}
>void main() {
>	foo();
>	bar();
>}
>% cc zap1.c zap2.c main.c
>% ./a.out
>Segmentation fault (core dumped)
>
>
>
>
>