On 5/09/2014 4:56 PM, Martin Packer wrote:
So tell me, if one wanted to achieve this apparently non-standard effect
how WOULD one go about it?
Write your own preprocessor!
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: [email protected]
Twitter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
From: David Price <[email protected]>
To: [email protected]
Date: 05/09/2014 09:54
Subject: Re: IBM C compiler substituting for macros inside
literals?
Sent by: IBM Mainframe Discussion List <[email protected]>
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
<[email protected]> 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 [email protected] 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 [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
