By the way, to answer the original question, what's wrong with
	/usr/share/doc/psd/06.Clang ?
It's been empty for a long time, it's just CRYING OUT for some useful content
to hold.  ;-)

Back to our rathole in progress:

> Currently, we appear to depend on the assumption that
> 	void foo(char c);
> 	void foo(c)
> 	char c;
> 	{}
> is accepted, and does the right thing.

Um, I thought "the right thing" was to *reject* it, because the latter
definition still requires argument promotion (i.e. it is compatible with
a prototype of void foo(int c) ).

>  I'm doing the proposal
> on eliminating old-style functions, and I'm giving this as
> prior art for preserving the syntax used in old-style definitions,
> but giving them the semantics of prototype declarations, i.e., no
> hidden promotions of argument types.

If code is going to break it should not break silently.  I can see forbidding
the old syntax on those grounds.

I think having NetBSD offer a C9X compilation system (as opposed to changing
all of NetBSD's source code to *be* C9X) raises the following questions:

(1) Will the compiler have a -traditional mode?  (That's up to the GCC people,
as I said, but looks likely.)

(2) Given that, will the shipped system header files directly support
applications which are written in K&R C (to the extent that they're supported
now)?

(3) If not, then if someone crafted an alternative set of header files for
legacy applications, would the result link with the standard system libraries?

(4) If someone had to hand-craft a backward-compatability library, would the
system go out of its way to prevent legacy applications from running just out
of spite?  ;-)

I seriously doubt things would get as bad as the last case, but it should be
obvious that case 2 is more desirable than 3 (trying to maintain two sets
of headers in parallel would be a pain), and 3 is by far better than 4 (i.e.
also having to maintain a parallel shim library).  But it certainly doesn't
need to be as easy to compile K&R as C9X (as long as one can bury the grungy
details in a makefile).  There is probably about a terabyte of existing code
somewhere between K&R and ANSI that just can't be ignored.