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