close-order manual reading

trainoff.pasa at XEROX.ARPA trainoff.pasa at XEROX.ARPA
Tue Jun 19 02:48:00 AEST 1984


> Just another note on the C preprocessor and on exegesis from K&R: I
had a
> program for which I thought I'd write a common macro to report errors,
and > > > wrote
> 
> 	#define error(s) fprintf(stderr, "prog: line %d--%s\n", (s))
> 
> to do the job, I thought. Feeling mildly smug, I compiled the program
that
> contained this #define, and came back with errors. Checking the resuls
from
> the preprocessor showed that the preprocessor was replacing the s in
%s
> with the actual parameter when I used the error macro.
> 
> Gee, I thought; doesn't the sentence under section 12.1, "Token
Replacement,"
> on page 207 of K&R,
> 
> 	Text inside a string or a character constant is not subject
> 	to replacement.
> 
> imply that that shouldn't happen? I thought it did, but
experimentation on
> a machine running 4.2 BSD (I was using a microcomputer C compiler the
first
> time around) gave the same results.
> 
> The fix to this particular problem is, of course, straightforward, and
I
> have done it and gone on my way, but I present it here as an example.
> To paraphrase Raymond Smullyan, doesn't this make you think that
there's
> something just a little bit wrong with English specification of
semantics?
> 
> 						James Jones

I too have run into this, however in a different context.  When I first
was learning C there was a macro in one of the libraries called DEBUG
which exploited this.  If memory serves me, it was defined as:

	#define DEBUG(var, type) printf("var = %type\n", (var));

It was quite convenient for dumping intermediates.  It just saved a bit
of typing and stood out in the code.  When the program was considered
completed, I would just globally comment them out or delete them.
Recently, I tried to recreate this macro on Whitesmith's C compiler only
to find out that it does work.  Your example compiles just as originally
intended.  I'm not sure which I prefer.  Whitesmith's treatment produces
fewer surprises but is less flexible.  One thing I am certain I would
prefer is uniformity.

					Steve Trainoff
					Xerox Special Information Systems
					Pasadena, CA.



More information about the Comp.lang.c mailing list