The requirement for the struct keyword when using the tag name is C-specific. C++ decided the tag by itself was sufficient for the compiler to determine it is the name of a struct type.
You appear to be compiling in XL as C code and in MVSC as C++ code. There are other differences in the languages that can cause code to compile successfully in one but not the other. For example, in C there is an implicit conversion between any pointer to object type and pointer to void while C++ requires a cast. > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Joseph Reichman > Sent: Saturday, January 18, 2020 2:56 PM > To: [email protected] > Subject: Re: Metal C using Z/OS macros in C macros > > 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:IBM- > [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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
