Statement terminators

Geoff Rimmer geoff at cs.warwick.ac.uk
Mon May 8 23:20:32 AEST 1989


In article <2296 at mit-caf.MIT.EDU> vlcek at mit-caf.MIT.EDU (Jim Vlcek) writes:
> In fact, I myself would lean the other direction and prefer that
> macros not follow the strict ``to the next newline'' rule, but rather
> have a more explicit means of terminating the definition body.

I agree that it can be *very* annoying having to backquote all the
newlines in macros (take a look at "putc" in stdio.h !)  But how else
could cpp be designed so it knows when to stop?  By matching the
parentheses/ brackets & braces?  Problem is some (admittedly
braindead) people write macros like
	#define ERROR fprintf(stderr,
and then use
	ERROR "This is an error\n");

Perhaps you could force the macro definition to appear within braces,
for example the above would be
	#define ERROR {fprintf(stderr,}
and when the text substitution is made, the braces will not be
inserted.  However, this could make some macros even more difficult to
read than having \'s down the RHS.  For example, I often use the macro,

	V--- Ha! Nuts to all you haters of case-sensitivity! :-)
#define Malloc(x)   ({char *tempptr=malloc(x); \
		      if (!tempptr) perror_("malloc failed");tempptr;})

(BTW this is only when I'm using gcc - so no flames!)

If I had to put the RHS in another set of braces, I'd have 3 types of
brackets - just to get rid of the backslash!

I guess having to backslash all the newlines is the "least bad"
solution to the problem of readability, although I'll agree that it
can be a pain in the <enter any part of the anatomy>.

> Jim Vlcek (vlcek at caf.mit.edu  uunet!mit-eddie!mit-caf!vlcek)

Geoff

	/---------------------------------------------------------------\
	|	GEOFF RIMMER  - Friend of fax booths			|
	|	email	: geoff at uk.ac.warwick.cs			|
	|	address : Computer Science Dept, Warwick University, 	|
	|		  Coventry, England.				|
	|	PHONE	: +44 203 692320 (10 lines)			|
	|	FAX	: +44 865 726753				|
	\---------------------------------------------------------------/



More information about the Comp.lang.c mailing list