This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

`Cpp: 'ICOM_FN(##xfn)' generates a warning :-(


  I'm having problems with the following piece of code (extracted from
Wine's source):

#define GetObject You_cannot_use_GetObject_in_this_context

#define ICOM_FN(xfn)    fn ## xfn
#define DECLARE1(xfn)    void ICOM_FN(xfn) (void);
#define DECLARE2(xfn)    void ICOM_FN(##xfn) (void);


   I expect to get (blank and not relevant lines removed):

void fnYou_cannot_use_GetObject_in_this_context     (void); 
void fnGetObject    (void); 

   But I've had problems with recent versions of gcc. One version
(20001002) produced:
test.c:6:38: warning: nothing can be pasted after this token
void fnYou_cannot_use_GetObject_in_this_context (void);
void fnYou_cannot_use_GetObject_in_this_context (void);

   But more recent versions work again so this seems to be fixed. But I
still get the following warning:
test.c:11:1: warning: pasting "(" and "GetObject" does not give a valid
preprocessing token

   Is this use of '##' still going to be supported in the future?
   Is it possible to not issue a warning in this situation (I know about
the macro vararg problem).

   Reading the Cpp documentation I see:

Attempting to paste two tokens which together do not form a valid  
preprocessing token The preprocessor currently warns about this and  
outputs the two tokens adjacently, which is probably the behavior the   
programmer intends. It may not work in future, though. Most of the time,
when you get this warning, you will find that `##' is being used  
superstitiously, to guard against whitespace appearing between two
tokens. It is almost always safe to delete the `##'.

   But this does not cover what I do which is to use the concatenation
operator to avoid the argument prescan described in 'Separate Expansion
of Macro Arguments'

We have explained that the expansion of a macro, including the
substituted arguments, is re-scanned for macro calls to be expanded.

What really happens is more subtle: first each argument is scanned
separately for macro calls. Then the resulting tokens are substituted
into the macro body to produce the macro expansion, and the macro
expansion is scanned again for macros to expand.

The prescan is not done when an argument is stringified or concatenated.

   Since this is unrelated to the macro vararg issue it would be nice if
there was a way to avoid the warning in this context (otherwise we'll
have to change the code and duplicate 30+ macros :-( ).

  I apologize if this is the wrong mailing list. Would gcc-bugs be more
appropriate (seems like it is more gnats oriented)?  
  jakub, Bernhard Rosenkraenzer told me you would be interested in being

Francois Gouget
               RFC 2549:
                IP over Avian Carriers with Quality of Service

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]