C standard revisions

[jbn at wdl1.UUCP]

        Some comments on the C revision follow; my previous posting of
	similar comments was reportedly garbled in transmission.

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

    3.  The problem of functions with variable numbers of arguments is
	an important one.  The (argc,argv) mechanism has proved very
	effective in dealing with variable numbers of arguments on the
	command line, and something like this is probably better than
	an ommitted-argument approach.  The type of the entries in argv
	remains a problem.  But the idea of passing an array of pointers
	and a count is a good one.  Few languages deal with this problem
	in a clean way; in most, I/O is a hack for this reason.  Lisp
	nlambdas are probably the cleanest solution in a widely used language.
	Ada has a sound approach to ommitted arguments, but it is complex
	and unsuited to C.

	The basic test for this mechanism is, of course, whether "stdio" can
	be written portably in C.  The ommitted argument approach fails this
	test, because there is going to be some limit on the number of
	arguments to the "printf" family of routines.  Worse, the approach
	of defining "printf" with a large number of arguments, some of
	which are ommitted, doesn't allow all the "printf"-like routines
	to use the same common routine ("doprint" in some implementations)
	in a sound way, because it implies references to parameters that
	weren't passed.  This is formally an error, and may be an actual
	error if your system doesn't allow stack growth on fetches, as well
	as stores.

	The (argc,argv) approach, on the other hand, handles this quite
	nicely.  This is in fact near to the way the present routines for UNIX 
	work, except that they use an implementation-dependent trick to access
	the stack directly, something which depends upon knowledge of 
	exactly how parameters are passed.  (There are other ways to
	pass parameters to subroutines than pushing them on the stack;
	there are compilers, for example, that put the first three arguments
	in registers and only use the stack if there are more than three
	arguments.  This provides a significant performance improvement
	on many machines.)  In fact, the UNIX library routines here are
	not portable across machines which grow the stack in different
	directions.

Other than the above, the standard revision looks good from the point of
view of someone concerned with portability.

					John Nagle