Thanks Looked up the Kernighan and Ritchie book the Bible on C and they had # too as character substitution
I did however find some differences between Microsoft C aka visual studio and XL compiler such as when casting a struct pointer in MSVC you can just cast the struct name preceded by * while XL you need the struct key word included > On Jan 17, 2020, at 5:14 PM, scott Ford <[email protected]> wrote: > > Check out Peter Relson’s Share presentation on Metal C , you can google it > >> On Fri, Jan 17, 2020 at 1:51 PM Joseph Reichman <[email protected]> >> wrote: >> >> Got it >> >> The # operator >> The # (single number sign) operator converts a parameter of a >> function-like macro into a character string >> literal. For example, if macro ABC is defined using the following >> directive: >> #define ABC(x) #x >> >> >> -----Original Message----- >> From: IBM Mainframe Discussion List <[email protected]> On Behalf >> Of Seymour J Metz >> Sent: Friday, January 17, 2020 1:36 PM >> To: [email protected] >> Subject: Re: Metal C using Z/OS macros in C macros >> >> z/OS Version 2 Release 4 XL C/C++ Language Reference, SC14-7308-40 >> >> https colon // >> www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sc147308/$file/cbclx01_v2r4.pdf >> >> Chapter 17. Preprocessor directives >> >> P. 405 >> >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> ________________________________________ >> From: IBM Mainframe Discussion List <[email protected]> on behalf >> of Joseph Reichman <[email protected]> >> Sent: Friday, January 17, 2020 1:18 PM >> To: [email protected] >> Subject: Re: Metal C using Z/OS macros in C macros >> >> The only issue I have looking in the documentation in the metal C >> reference or The XL\C language reference which has some documentation on >> __asm >> >> No where is thre a thing about # and text substitution >> >> >> >> >> >>>> On Jan 17, 2020, at 12:48 PM, Charles Mills <[email protected]> wrote: >>> >>> I am not an expert at all on C __asm and only barely something of an >>> expert on C macros so I avoided wading into this one. I will say >>> >>> 1. What @Peter Farley says sounds right to me. >>> >>> 2. Keep in mind that a macro definition in C does not "do anything" >>> (so to speak -- of course it does something). It just sets up future >>> text substitution. So at the time you define your macro no C variables >>> need exist. There are no preexisting conditions for a macro >>> definition. Your macro must be a syntactically valid macro, that's >>> all. Macro definition knows nothing about variable declarations -- you >>> are just setting up some rules for text substitution. >>> >>> Then when you invoke your macro, the C preprocessor will do its text >>> substitution magic. It will use your macro definition and your macro >>> invocation to create some alleged C code. Somewhat later, the C >>> compiler will attempt to compile that alleged C code. So if that C >>> code references a variable, then yes, that variable will have to have >>> been previously (earlier in the source code file) declared. Earlier as >>> in before the invocation of the macro, not necessarily before the >> definition of the macro. >>> >>> Charles >>> >>> >>> -----Original Message----- >>> From: IBM Mainframe Discussion List [mailto:[email protected]] >>> On Behalf Of Farley, Peter x23353 >>> Sent: Friday, January 17, 2020 8:31 AM >>> To: [email protected] >>> Subject: Re: Metal C using Z/OS macros in C macros >>> >>> The %0 and %1 are parameters to the __asm function, it will do the >>> substitution of the 2nd and 3rd parameter in the __asm(...) invocation >>> into the %0 and %1 spots in the 1st parameter. >>> >>> And I concur with your description - the *invocation* of the "SETUP(...)" >>> macro will specify the variables to be used and *those* variables are >>> the ones that need to be defined, "xx" and "yy" in your example. >>> >>> If the OP (Mr. Reichman) codes the *invocation* of the SETUP macro as >>> follows: >>> >>> SETUP(supstate,key) >>> >>> Then both "supstate" and "key" must be defined C variables. >>> >>> The __asm function does not *define* variables, it just *uses* them. >>> The variables mentioned in an __asm invocation must already be defined >>> in the C code. >>> >>> Peter >>> >>> -----Original Message----- >>> From: IBM Mainframe Discussion List <[email protected]> On >>> Behalf Of retired mainframer >>> Sent: Friday, January 17, 2020 11:06 AM >>> To: [email protected] >>> Subject: Re: Metal C using Z/OS macros in C macros >>> >>> In you C code, when you "invoke" the macro, you would provide the >>> values of the two macro parameters. Something like >>> SETSUP(xx,yy) >>> It is the xx and yy that would show up inside the two parenthetical >>> expressions in the generated code. Keep in mind that a C macro >>> performs simple text substitution long before the actual compilation >> starts. >>> >>> Based on the generated code you show, you would not terminate the >>> above invocation with a semicolon. >>> >>> I've never used __asm but is >>> __asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(xx), "=s"(yy) ) what you >>> want the compiler to see? >>> >>> Are you using %0 and %1 to mean the macro parameters? That is not the >>> way C macros work. >>> >>> It looks like there should be a line continuation back slash following >>> the left brace. I don't think you want the one that follows the right >>> brace since there is no following line. >>> >>>> -----Original Message----- >>>> From: IBM Mainframe Discussion List <[email protected]> On >>>> Behalf Of Joseph Reichman >>>> Sent: Friday, January 17, 2020 5:22 AM >>>> To: [email protected] >>>> Subject: Metal C using Z/OS macros in C macros >>>> >>>> Just wondering if I can do something like this >>>> >>>> #define SETSUP(supstate,key) \ >>>> { >>>> __asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(supstate), "=s"(key) ) \ >>>> } \ >>>> >>>> Seems like the variables have to be defined >>> >>> ---------------------------------------------------------------------- >>> >>> This message and any attachments are intended only for the use of the >>> addressee and may contain information that is privileged and >> confidential. >>> If the reader of the message is not the intended recipient or an >>> authorized representative of the intended recipient, you are hereby >>> notified that any dissemination of this communication is strictly >>> prohibited. If you have received this communication in error, please >>> notify us immediately by e-mail and delete the message and any >> attachments from your system. >>> >>> ---------------------------------------------------------------------- >>> 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 >> >> ---------------------------------------------------------------------- >> 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 >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > -- > Scott Ford > IDMWORKS > z/OS Development > > ---------------------------------------------------------------------- > 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
