Let ME try for a new topic...

[John P. Linderman]

externs and include files are two subjects guaranteed to raise my blood
pressure.  The decision by certain compiler purveyors that variables
could be "defined" (i.e. appear without an extern) only once caused
many useful programs to be uncompilable.  Many of us considered that it
was more important to keep software working than to satisfy some
bureaucrat's concept of "clean coding".  (Please spare me chapter 11,
verse 2 from K&R.)  We adopted the following artifice to simplify
maintenance of code that included external variables in .h files.
If the include file used to look like

    int i;
    char foo[] = "bar";

we would replace them with

    #ifdef  OWNER
    #define EXTERN
    #define EXTINIT(X) = X
    #else
    #define EXTERN extern
    #define EXTINIT(X)
    #endif  OWNER

    EXTERN int i;
    EXTERN char foo[] EXTINIT("bar");

In the makefile, we would then include a -DOWNER flag in exactly one
cc line, usually the one for the main routine.  This made it easy to
get programs working again without having to duplicate headers or
rewrite code.

Speaking of include files, I get constant complaints from users whose
code won't compile, either because they included <sys/stat.h> but not
<sys/types.h> (which stat.h requires, at least under 4.2), or because
they managed to include <sys/types.h> twice.  The latter problem is
particularly annoying because it is so easy to fix.  All include
files ought to be of the form

#ifndef typesdefined
#define typesdefined
<former contents of types.h file>
#endif  typesdefined

so multiple inclusions cause no problems.  I am hesitant to fix this
unilaterally, because then programs that work fine here might not
compile elsewhere.  But it ought to be fixed, both under Berkeley
and System 5.  Once that fix is in for all header files, it would be
possible for <sys/stat.h> to do its own include of <sys/types.h>,
since repeated inclusions would do no semantic damage.  This proposal
is microscopically harder to defend: the redundant includes might
make compiles slower.  I find it hard to get excited about slower
compiles, but I'm willing to accept that there may be places where
it is important.

John P. Linderman  Department of War on Morons  allegra!jpl