mike@WISDOM.BITNET (Mike Trachtman) (10/30/85)
Consider the folowing short program.
#define BAD_SEGMENT 29
#define ERROR(number) printf("Error number %d\n",number);
main() {
/* typically there would be here some condition test
if (somthing)
*/
ERROR(BAD_SEGMENT);
}
what should this program do ????
On the compilers I have tried it, (vax 4.2, Vms C, Sun 2.0),
it has output of:
Error BAD_SEGMENT 29
rather than
Error number 29
which I would have expected.
Is this correct ???
I would think that anything inside double quotes is protected
from any/all substitution, and that the preprocessor, would
not do the parameter replacement.
Mike
Mike Trachtman
My address:
mike@wisdom (BITNET)
mike%wisdom.bitnet@wiscvm.ARPA (ARPA/CSNET)
mike%wisdom.bitnet@berkley (ARPA/CSNET)
and if all else fails (ONLY for VERY short items)
...!decvax!humus!wisdom!mike (UUCP)jqj@cornell.UUCP (J Q Johnson) (10/31/85)
Most versions of pcc ignore stringness (``"'') when looking for tokens for macro replacement. Thus #define foo(a) "This string contains a" expands the call ``foo(X)'' to "This string contains X" K&R are silent on the lexical issues involved, so this cannot be considered incorrect. However, some compilers, notably Tartan C, behave differently, and expand the above example without substituting the ``a''. A related issue is handling of comments in the preprocessor. cpp permits #define makesym(a) foo/**/a which expands ``makesym(X)'' to ``fooX'' (unless, of course, -C is specified in which case the comment is retained). Other compilers might legitimately strip the comments before parsing the macro definition, and thus might not see the ``a'' in the definition as a separate token to be substituted, or might substitute white space for the /**/, resulting in an expansion to ``foo X''.
john@basser.oz (John Mackin) (11/02/85)
In article <270@cornell.UUCP> jqj@cornell.UUCP (J Q Johnson) writes: > Most versions of pcc ignore stringness (``"'') when looking for tokens > for macro replacement. > [ ... ] > K&R are silent on the lexical issues involved, so this cannot be considered > incorrect. I couldn't let such a glaring misstatement pass. Page 207, sec. 12.1: ``Text inside a string or a character constant is not subject to replacement.'' Disclaimer: I personally think that the book is *wrong* on this point, as evidence the fact that DMR's own original PDP-11 C system did do such substituion. I take issue here only with the fact that Mr. Johnson has misrepresented the book's position. John Mackin, Basser Department of Computer Science, University of Sydney, Sydney, Australia seismo!munnari!basser.oz!john john%basser.oz@SEISMO.CSS.GOV
chris@umcp-cs.UUCP (Chris Torek) (11/03/85)
In article <473@basser.oz> john@basser.oz (John Mackin) writes: >In article <270@cornell.UUCP> jqj@cornell.UUCP (J Q Johnson) writes: >> Most versions of pcc ignore stringness (``"'') when looking for tokens >> for macro replacement. ... K&R are silent on the lexical issues >> involved, so this cannot be considered incorrect. >I couldn't let such a glaring misstatement pass. Page 207, sec. 12.1: > ``Text inside a string or a character constant is not > subject to replacement.'' Surprise, surprise, this is actually ambiguous. When I first read this I assumed it meant `text inside a string or character constant anywhere'. It really means `text inside a string or character constant (except in the replacement portion of a macro)'. Unfortunately the former is the more reasonable interpretation (naturally---it is mine :-) ), so the ANSI standard has settled on that, and introduces some new `experimental' `stringizing' macro expansion features. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
ron@BRL.ARPA (Ron Natalie) (11/04/85)
>I couldn't let such a glaring misstatement pass. Page 207, sec. 12.1: > > ``Text inside a string or a character constant is not > subject to replacement.'' Well, this is out of context a bit. It is ambiguous from reading this statement whether it is talking about character constants in the text of the program, or if this statement should be extrapolated to me within the macro definition itself. Notably, the UNIX preprocessors out of Bell all did the substitution. The C Puzzle Book makes use of it, however the compiler we were evaluating by feeding the C puzzles did not substitute. -Ron
rcd@opus.UUCP (Dick Dunn) (11/04/85)
> Most versions of pcc ignore stringness (``"'') when looking for tokens > for macro replacement. Thus > #define foo(a) "This string contains a" > expands the call ``foo(X)'' to > "This string contains X" > > K&R are silent on the lexical issues involved, so this cannot be considered > incorrect... Foo. Come on, folks! The relevant section of K&R is easy enough to find--it's called "Token Replacement". It's only half a page long and not that hard to read. Read along with me... Text inside a string or a character constant is not subject to replacement. Get it? -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Never attribute to malice what can be adequately explained by stupidity.
herbie@polaris.UUCP (Herb Chong) (11/06/85)
In article <197@opus.UUCP> rcd@opus.UUCP (Dick Dunn) writes: >Foo. Come on, folks! The relevant section of K&R is easy enough to >find--it's called "Token Replacement". It's only half a page long and not >that hard to read. Read along with me... > > Text inside a string or a character constant is not subject to > replacement. > >Get it? i disagree. K&R does not mention what happens at macro definition time. you have just described the case for macro recognition and substituion. in fact, K&R's description of the preprocessot leaves a lot to be desired, and so does the semantic definition of the language. Herb Chong... I'm still user-friendly -- I don't byte, I nybble.... New net address -- VNET,BITNET,NETNORTH,EARN: HERBIE AT YKTVMH UUCP: {allegra|cbosgd|cmcl2|decvax|ihnp4|seismo}!philabs!polaris!herbie CSNET: herbie.yktvmh@ibm-sj.csnet ARPA: herbie.yktvmh.ibm-sj.csnet@csnet-relay.arpa ======================================================================== DISCLAIMER: what you just read was produced by pouring lukewarm tea for 42 seconds onto 9 people chained to 6 Ouija boards.