So tell me, if one wanted to achieve this apparently non-standard effect how WOULD one go about it?
Not that I want to but it HAD to be asked. :-) Thanks, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: David Price <da...@bigpond.net.au> To: IBM-MAIN@LISTSERV.UA.EDU Date: 05/09/2014 09:54 Subject: Re: IBM C compiler substituting for macros inside literals? Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> Hi Glen! For the benefit of others, K&R = "The C Programming Language" by Kernighan & Ritchie. Appendix A C REFERENCE MANUAL, section 12.1 Token Replacement is on page 207 in the original 1978 edition. Section 12.1 explicitly deals with both #define identifier token-string and #define identifier( identifier , ... , identifier ) token-string [that is, simple #define constants and the almost-as-simple macro functions]. It says "Text inside a string or a character constant is not subject to replacement". This 1978 K&R is prior to the November 15, 1978 extensions to C regarding Structure Assignment and Enumeration types. (I say this just to establish that the above indeed relates to the earliest widely-circulated definition of C.) The K&R book's Appendix A "C Reference Manual" was often reprinted as part of the AT&T UNIX manuals. I wonder if those few early C Macro Preprocessors that broke this rule did so knowingly (as a feature to get inside a string before this was provided for) or unknowingly (simplistic coding). I could forgive this for something like the early Portable C Compiler where the focus was on providing a simple C compiler that could compile a more sophisticated one. Then again, the C Macro Preprocessor was a separate program in those days, so the Portable C Compiler could just as easily have used a copy of a production C Preprocessor, so its logic should have been correct. (I'm not saying the Portable C Compiler had the bug - just wildly speculating as to where the coding error may have come from.) -- dap On Thu, 4 Sep 2014 02:36:51 -0700, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: >> it must be bug with the macro preprocessor used by USS's cc comand. >> Even K&R's 1978 definition of C makes it clear that arguments >> inside "..." strings are not to be substituted. > >Two different questions. > >If you: > >#define d 5 >printf("%d", 3); > >the d won't be replaced. That is, in preprocessor terms, a very >different question from: > >#define S(d) printf("%d", d) > >The person writing a macro with arguments has full control over >the names, and can choose them to match or not. This allows for: > >#define debug(x) printf("x=%d\n", x) > >ANSI added the stringizing operation, and then removed the >replacement inside strings. > >While not explicitly stated in K&R1, it is the normal case >for non-ANSI preprocessors. > >-- glen ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
