C standard revisions

[Henry Spencer]

Some replies to some of wdl1!jbn's comments:

    1.	It is permissable to change the language incompatibly if machine 
	conversion is possible and straightforward, and it is better to 
	change the language incompatibly than to introduce painful mechanisms 
	for backward compatibility.  If this is unacceptable, the obsolete
	constructs should be explictly defined as features retained for
	backward compatiblity in this revision and subject to removal in
	a later revision, and compilers should issue warning messages
	when such constructs appear.  The way the transition from "=+" to
	"+=" was handled is an example of the right way to do this.

In fact, this is very difficult.  The transition from "=+" to "+=" took
perhaps five years, and I gather it caused considerable unhappiness
among some of the customers.  Yet this was pretty trivial, and it was
exactly the sort of thing where machine translation can do the whole
job for you.  I fear that the tremendous body of existing C code already
has huge inertia; we are stuck with backward compatibility whether we
like it or not.  If you want a (semi)formal proof of this, consider:

(a) The C standard is most unlikely to succeed if it faces
	active opposition from AT&T.  Unix is still the home
	of C, although many C implementations have left home,
	and AT&T's C compilers remain very influential.
(b) AT&T is most unlikely to endorse something for external
	release if it's unacceptable for internal use.  This
	implies that the new C standard has to pass muster
	within AT&T.  (Please don't tell me that this is really
	distasteful.  True, but beside the point.)
(c) AT&T won't endorse something for internal use that breaks
	huge masses of existing applications code.  Note that
	I didn't waffle with "most unlikely" on this one, because there
	is already one case on record where a seemingly-desirable
	change in AT&T C compilers had to be withdrawn because the
	internal customers absolutely refused to accept it -- it
	broke too much code.

Changes can be made, but even for trivia like "+=" it's already a very
slow and painful process.  Radical change is out.
    
    2.  If syntax for checking procedure calls across compilation units
	is to be introduced at all, it should be mandatory.  Otherwise it
	is almost useless as a mechanism for preventing bugs.  Also, if
	it is mandatory, compilers can generate better code when passing
	small types; the present definition requries that all chars, for
	example, be expanded to ints in parameter passing, which makes
	calling functions more expensive for C than it should be.

Problems with mixing old and new function-declaration arrangements worry
many people.  But the break-all-the-old-code problem is severe here.

    3.  The problem of functions with variable numbers of arguments is
	an important one...

Agreed.  The committee is interested in trying to define a standard way
of handling this problem.  It's very hard.  (Please don't tell me that
it's really easy because there is a simple solution, namely X; believe
me, I have seen all the simple ideas, and none of them work everywhere.)
(If you *must* send me your latest brainstorm in the belief that I've
never seen it before, **PLEASE** do so by private mail, not by posting it
to the whole newsgroup!)  I suspect that the only fully satisfactory way to
do it is to assume that variable-argument procedures are fully declared
(e.g. "extern printf(char *,);") before use, so that the compiler can
do something special about calls to them.  Given this, something like
the "(argc, argv)" convention would be possible.  I don't know if the
committee is planning to do exactly that, but it seems the right direction.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry