Hi Glen!
For the benefit of others, KR = 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
: 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
/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, KR = The C Programming Language by Kernighan
Ritchie.
Appendix A C REFERENCE MANUAL, section
On Fri, 5 Sep 2014 07:00:24 -0700, Charles Mills wrote:
Not sure if your question is intended to be serious but on an ANSI C
compiler there is no way to do substitution inside a literal string.
However, what could have been accomplished with this:
#define debug(a) printf(the value of a is %d\n,
Mills
Sent: Friday, September 05, 2014 7:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM C compiler substituting for macros inside literals?
Not sure if your question is intended to be serious but on an ANSI C
compiler there is no way to do substitution inside a literal string.
However
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM C compiler substituting for macros inside literals?
it must be bug with the macro preprocessor used by USS's cc comand.
Even KR's 1978 definition of C makes it clear that arguments inside
... strings are not to be substituted.
Two different
Charles
Yes, I assumed this and used the macro invocation in my test compile.
And for completeness, I can confirm that when I use cc -E on my 1.12 system I
get the same results as you i.e.:
printf(%fox %s %s %s %s\n, 5, The, quick, brown, fox);
Regards
Andy T.
On 2 Sep 2014, at 03:20,
On Tue, 2 Sep 2014 08:31:50 +0100, Andy Taylor wrote:
Charles
Yes, I assumed this and used the macro invocation in my test compile.
And for completeness, I can confirm that when I use cc -E on my 1.12 system I
get the same results as you i.e.:
printf(%fox %s %s %s %s\n, 5, The, quick, brown,
Charles
I compiled this on a 1.12 system under both batch and USS and results were as
expected. Preprocessor output under USS using a c89 -V gives:
STRINGZ(The, quick, brown, fox);
printf(%d %s %s %s %s\n, 5, The, quick, brown, fox);
You mention seeing the
traditional batch.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Andy Taylor
Sent: Monday, September 01, 2014 3:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM C compiler substituting for macros inside literals?
Charles
I
I realize I also left out one line of the problem.
*For the macro invocation*
STRINGZ(The, quick, brown, fox);
the compiler is making of it
printf(%fox %s %s %s %s\n, 5, The, quick, brown, fox);
the compiler is making of it:
printf(%fox %s %s %s %s\n, 5, The, quick, brown, fox);
On Mon, 1 Sep 2014 16:26:34 -0700, Charles Mills wrote:
Sorry. cc command.
cc -E StringMacroTest.c
Interesting! Happens with cc command but not with c89 or c++ commands.
The cc command is not ANSI C. xlc, c89, and c99 are ANSI C.
See this page from chapter 24 of the C/C++ User's Guide for
Charles Mills write:
#define V 5
#define STRINGZ(a,b,c,d) printf(%d %s %s %s %s\n, V, #a, #b, #c, #d)
STRINGZ(The, quick, brown, fox);
the compiler is making of it
printf(%fox %s %s %s %s\n, 5, The, quick, brown, fox);
As I
Charles,
it must be bug with the macro preprocessor used by USS's cc comand.
Even KR's 1978 definition of C makes it clear that arguments inside ...
strings are not to be substituted.
An obvious workaround would be
#define V 5
#define
14 matches
Mail list logo
