Subject: Re: Documentation/languages...
To: None <email@example.com, firstname.lastname@example.org>
From: Peter Seebach <email@example.com>
Date: 05/18/1997 23:41:01
>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
>> 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
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
>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.