>By the way, to answer the original question, what's wrong with
>	/usr/share/doc/psd/06.Clang ?

Nothing, and when I have the time to do the C reference manual I've been
planning to write for the last 3 or 3.5 years, I'll probably try to write one
that fits there.

I was looking at the much less ambitious project of just documenting the local
color.

>> 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) ).

You aren't required to; it looks to me like all of the 'shall' clauses it
violates are in semantics sections, not constraints sections.

gcc will complain, but only in -pedantic.  Try compiling with -pedantic some
time and see what happens to the source tree.  I haven't dared, myself.

The decision to treat an old-style definition following a prototype as
compatible with that prototype is a reasonable one, although it's certainly
not the only reasonable one.

I'm currently leaning towards wanting C9X to *always* treat the old-style
definitions as equivalent with the prototypes they spell, i.e., eliminate the
argument promotion entirely.  Since old-style functions are obsolescent, it's
no loss if it breaks something, right?  :)

(More importantly, any code affected will likely require a -traditional option
or the equivalent anyway.)

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

Yes.  That's our fallback position.  At this point, I'd bet that old-style
definitions as we know them are dead.  I would like to keep the more
convenient syntax, but get type checking.  I dunno if it'll happen.

>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.)

I think it should; it currently does, and there's some discussion of renaming
-traditional to -c78, so we can have -c89 and -c9x in the future.

>(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)?

I would recommend against this.  Unprototyping is trivial and mechanical, but
the alternative leaves us with, IMHO, crufty headers.

>(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?

Most likely, simply because there are very few functions (indeed, I can't
think of a single one) which would be used by a legacy application but whose
argument types are going to be affected by any of this.  :)

>(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 hope not.  Much though I want to see code updated into the current decade,
I'm okay with the idea that rewriting 2 million lines of code may not be cost
effective.

>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.

I think the thing to do is to see if there's a way to get prototyped modern
headers to compile with old-style code.  If there there is, we're probably
going to be fine with that.

-s