1

-- Update 20200114: New version of #define Entry macro and new results

Another newbie sort of question here. I'm trying to create a #define macro that I can use to generate the entry to a routine along with it's #pragma prolog() and #pragma epilog():

#pragma prolog(<entryname>," <prologasmstuff>")
#pragma epilog(<entryname>," <epilogasmstuff>")
functiontype entryname (<parameters>) {

I've tried a couple of variations of the following (this represents today's attempt):

#define Entry(            \                           
           EntryType      \                           
          ,EntryName      \                           
          ,EntryVariables \                           
          ,PrologString   \                           
          ,EpilogString   \                           
          )               \                           
_Pragma("prolog(EntryName,\" PrologString\"")  \      
_Pragma("epilog(Entryname,\" EpilogString\"")  \      
EntryType EntryName (EntryVariables) {

The preprocessor doesn't seem to be able to make this work. The macro is invoked via:

Entry(void,wto,char * MsgArea," CKKIP31P"," CKKEP31P")

And the compiler burps up the following:

68       |Entry(void,wto,char * MsgArea," CKKIP31P"," CKKEP31P")                                            |   1005
68       +_Pragma("prolog(EntryName,\" PrologString\"") _Pragma("epilog(Entryname,\" EpilogString\"") void \+   1005
68       +wto (char * MsgArea) {                                                                            +   1005
69       |                                                                                                  |   1006

The compiler issues the following messages:

WARNING CCN3224 SSAF.METALC.C(TSTENTRY):68    Incorrect pragma ignored.
WARNING CCN3224 SSAF.METALC.C(TSTENTRY):68    Incorrect pragma ignored.

Any thoughts on how to see what the "resolved" #pragmas look like or what's wrong with them?

Thanks, Scott Fagen

  • My gut says no, as I believe that the preprocessor looks for #pragma in the original source string, and does not rescan substitution strings. – zarchasmpgmr Jan 14 '20 at 01:51
  • possible duplicate: https://stackoverflow.com/questions/2831934/c-preprocessor-using-if-inside-define In short, you cannot use preprocessor directives within a macro expansion. – meat Jan 14 '20 at 03:34
  • Ray/Meat, per "I believe that the preprocessor looks for #pragma in the original source string, and does not rescan substitution strings." From https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html: "C99 introduced the _Pragma operator. This feature addresses a major problem with ‘#pragma’: being a directive, it cannot be produced as the result of macro expansion. _Pragma is an operator, much like sizeof or defined, and can be embedded in a macro." So I *think* that I'm using the _Pragma in the proprer spirit. Maybe it's as stupid as just saying _Pragma rather than _pragma??? Let me try. – Scott Fagen Jan 14 '20 at 17:16
  • I think you should reconsider this idea! IMO, using the #pragma is easier to understand. There is nothing worse than macros obscuring function definitions/declarations which may confuse modern editors that parse the code for context assist. – David Crayford Jan 28 '20 at 06:17

1 Answers1

1

This may do what you want, give it a try:

#define STRINGIZE(x) #x

#define Entry( \
  EntryType \
  ,EntryName \
  ,EntryVariables \
  ,PrologString \
  ,EpilogString \
  ) \
_Pragma( STRINGIZE( prolog(EntryName,PrologString) )); \
_Pragma( STRINGIZE( epilog(EntryName,EpilogString) )); \
EntryType EntryName( EntryVariables ) { }

Entry(void, wto, char * MsgArea, " CKKIP31P", " CKKIE31P")
Milos Lalovic
  • 554
  • 3
  • 10