> Having prototypes is a good thing -- for ANSI-C compilers.  Being
> able to compile with a non-ANSI-C compiler is still essential.  These
> two goals are *not* at conflict.

They perforce are to some extent, since you can't both have prototypes
and not have prototypes.  Stuff like __P() makes it relatively painless
in most cases, by making you tweak at most one thing to turn prototypes
on or off.  We are depending on a gcc extension (see below), but it is
relatively easy to write code that's compilable under old compilers and
still fully prototyped and correct under gcc (but in some cases not
other, more strictly ANSI, compilers).  Here's a snippet from the gcc
2.7.0 distribution's extend.texi that talks about the extension:

+----------------
| @node Function Prototypes
| @section Prototypes and Old-Style Function Definitions
| @cindex function prototype declarations
| @cindex old-style function definitions
| @cindex promotion of formal parameters
| 
| GNU C extends ANSI C to allow a function prototype to override a later
| old-style non-prototype definition.  Consider the following example:
| 
| [example, essentially (macros expanded)
| 	int foo(uid_t);
| 	int foo(x) uid_t x; { ... }
| ]
| 
| Suppose the type @code{uid_t} happens to be @code{short}.  ANSI C does
| not allow this example, because subword arguments in old-style
| non-prototype definitions are promoted.  Therefore in this example the
| function definition's argument is really an @code{int}, which does not
| match the prototype argument type of @code{short}.
| 
| This restriction of ANSI C makes it hard to write code that is portable
| to traditional C compilers, because the programmer does not know
| whether the @code{uid_t} type is @code{short}, @code{int}, or
| @code{long}.  Therefore, in cases like these GNU C allows a prototype
| to override a later old-style definition.  More precisely, in GNU C, a
| function prototype argument type overrides the argument type specified
| by a later old-style definition if the former type is the same as the
| latter type before promotion.
+----------------

> What's too bad is that gcc isn't split into a nice neat compiler and
> a super-ANSI-fied lint.  A full-blown implementation of a lint-like
> tool, if based on the front-end of gcc, could be an amazing tool.
> Then for those of us who've already run our code through such a
> checker, a lean, mean, compiler could also be built to skip all the
> checks and just do what it's supposed to do.

Perhaps.  But why bother?  A lot of the complexity and expense goes
into things that (like, say, preprocessing and codewalking) have to be
done in both cases.  Keeping it all together in one program makes
maintenance a good deal easier, and if you don't want to pay the price
of the warnings, just don't turn on those flags and the only price
you'll pay is some text segment space that never gets used.  And a few
tests to see if you turned on the flag; I think that price is tiny for
the benefits gained.

Besides, how often do you just recompile untouched code?  I do this
pretty damn seldom; I'd always be running the full-checking version.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu