On Fri, 2007-11-16 at 18:58 -0800, Ben Pfaff wrote: > "J. Mayer" <[EMAIL PROTECTED]> writes: > > > On Fri, 2007-11-16 at 21:32 +0100, andrzej zaborowski wrote: > >> I think a line like > >> > >> #define inline __attribute__ (( always_inline )) inline > >> > >> in dyngen-exec.h should be > > > > As I already pointed it in the first message of the thread, this kind of > > define would expand recursivelly, [...] > > No. A macro is not expanded within its own expansion. See ISO > C99:
I just take a look of what happens in *real life* while compiling the linux kernel which uses such a definition.... As I reported, I had compilation problems due to this behavior and did inspect the preprocessor output and saw this result. I did not check if it happens only with some versions of gcc or if this behavior has been changed with newer releases, I have to admit. > > 6.10.3.4 Rescanning and further replacement > [...] > 2 If the name of the macro being replaced is found during this > scan of the replacement list (not including the rest of the > source file's preprocessing tokens), it is not replaced. > > If it still bothers you, you could write it as > #define inline __attribute__ (( always_inline )) __inline__ > since GCC accepts __inline__ as a synonym for inline. You're right, this would be a good solution to avoid many changes in the code. -- J. Mayer <[EMAIL PROTECTED]> Never organized
