jejones@ea.UUCP (06/11/84)
#N:ea:5700011:000:1174 ea!jejones Jun 11 14:24:00 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
gwyn@BRL-VLD.ARPA (06/17/84)
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> The real problem with parameter substitution inside a string is that the Reiser C preprocessor and the C compiler disagree about such things. There was a USENIX session last week wherein Larry Rossler nicely summarized the current state of the ANSI C language specification; one of the things he mentioned was that the preprocessor facilities are being more carefully defined and intergrated into the language.
trainoff.pasa@XEROX.ARPA (06/18/84)
> 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.