ANSI C Comments

[Walter Bright]

Some comments on the ANSI C Standards Draft, Nov 12, 1984.

I. PREPROCESSOR

	1) What happens for the definition

		#define a() texta
		#define b textb

	   and the following appears in the C code:

		a()
		a
		b()
		b

	   Are they substituted as:

		texta
		syntax error
		textb()
		textb

	   Or as:

		texta
		texta
		textb
		textb

	   Basically, is a() interpreted as a macro with no arguments
	   or as a macro with an argument list that is empty?

	2) Along similar lines, how does one specify a blank argument?
	   Such as:

		#define a(b)	(b - c)
		a()		/* expands to ( - c)	*/

	   This is explicitly not allowed in the standard, although
	   it would not cause any problems to allow it.

	3) What is the behavior of:

		#define a text /* new-line
		*/ text2 new-line

	   Is it equivalent to:

		#define a text  text2 new-line

	4) How about a #exit directive and a #message directive?

		#exit constant-expression new-line

	   would cause the compiler to halt compilation with an
	   exit status given by constant-expression.

		#message string new-line

	   would print the message during the compilation.
	   For example:

		#ifndef	feature
		#message "feature is not implemented"
		#exit 1
		#endif

II. HELP FOR OPTIMIZERS

	Optimizing compilers can be helped considerably by the
	following restrictions placed on the language:

	1) No two distinct external identifiers can refer to the
	   same storage location. Note that it is only possible
	   to get this to happen if you link in assembly language
	   routines.

	2) If the address of a particular automatic was never taken,
	   it is assumed to never be referenced or modified by
	   an indirect assignment or reference.

		int *p;
		f()
		{	int a;
 
			g(*p);		/* could not possibly refer to a */
			*p = 5;		/* could not possibly point to a */
		}

	3) Rule 2 also implies that a compiler could put an automatic
	   in a register if nobody ever took its address. Some compilers
	   (VAX VMS C and Greenhills C) do this.

	4) Some sort of construct telling the compiler that it can
	   pass this argument to a function in a register. Currently,
	   since the compiler knows nothing about the called function,
	   all parameters must be placed on the stack (since the callee
	   could try to take the address of a parameter).

	   Passing args on the stack instead of in registers is a major
	   source of inefficiency in compiled code.

	   This rule would also imply that variable argument lists
	   cannot 'cross' a registered argument. For example:

	   f(a,b,c)	where b is passed in a register

	   one cannot access c by taking a pointer to a and incrementing it.

	   A possible syntax is an extension to the current method for
	   specifying the number and types of parameters:

		extern int f(int,register int,int);
		...
		f(a,register b,c)
		int a,b,c;
		{
			...
		}

	   This is NOT the same as the current

		f(a,b,c)
		int a,c;
		register int b;
		{}

	   as b must still be passed on the stack, then copied into
	   a register.

Walter Bright, Senior Software Engineer
Data I/O, 10525 Willows Road NE, P.O. Box 97046, Redmond, WA 98073-9746

			... uw-beaver!teltone!dataio!bright