Okay, a specific example of a gcc quirk:

In ANSI mode, we declare unvis(3) as
	int unvis(char *, char, int *, int);
but the actual library declaration is
	int unvis(a, b, c, d)
		char *a;
		char b;
		int *c;
		int d;

These *are not compatible*.  We are lying.  We declare unvis to take
a 2nd argument of type "char", but then define it taking a second
argument of type "int".  (Remember, old-style functions promote,
but prototypes don't.)

This is Wrong.  Now, it may be that the mistake was dmr's decision
to have default promotions.  It may be DEC's fault for making an
architecture where they made sense.  It may be ISO's for the non-promoting
prototypes.

But it could also be ours for trying to mix incompatible declarations, and
*THAT* is the only one we can fix.

In terms of consistency, I'd rather have a prototype-free code tree
than have inconsistant declarations.  Unfortunately, compliance declares
that we must prototype a fair number of functions, after which consistency
demands prototypes for the rest.

I'm not entirely happy with this; I really don't see a good answer.

The answer I dislike least is that we allow pure-ANSI code in new
work and patches, and let time pass a little.

-s