Yes, please do it. I created the INLINE macro, and I can see the awful confusion being created here, so please do what needs to be done to clarify things. Then, *document* how it works in the source file, where the macros are defined! Hrvoje Niksic wrote: -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/typing.html.

Hrvoje> "Kirill 'Big K' Katsnelson" <kkm(a)dtmx.com&gt; writes: Hrvoje> Beware, INLINE in XEmacs is not what you might think it is. Maybe Hrvoje> this is how Andy got burned. Hrvoje> #ifndef NOT_C_CODE Hrvoje> #ifdef __cplusplus Hrvoje> #define HAVE_INLINE 1 Hrvoje> #define INLINE inline Hrvoje> #else /* not C++ */ Hrvoje> /* Does the keyword `inline' exist? */ Hrvoje> #undef HAVE_INLINE Hrvoje> #undef inline Hrvoje> # ifdef HAVE_INLINE Hrvoje> # ifdef __GNUC__ Hrvoje> # ifdef DONT_EXTERN_INLINE_FUNCTIONS Hrvoje> # define INLINE inline Hrvoje> # else Hrvoje> # define INLINE extern inline Hrvoje> # endif Hrvoje> # else Hrvoje> # define INLINE static inline Hrvoje> # endif /* __GNUC__ */ Hrvoje> # else Hrvoje> # define INLINE static Hrvoje> # endif /* HAVE_INLINE */ Hrvoje> #endif /* not C++ */ Hrvoje> #endif /* C code */ Hrvoje> Notice how in almost all files INLINE is #defined to _extern_ inline, Hrvoje> not to static or static inline as one would assume. This is so that Hrvoje> the inline functions defined in headers work right. Hrvoje> I think we should change it so that: Hrvoje> * we rename existing INLINE to HEADER_INLINE, so that at least the Hrvoje> name suggests what's going on. Hrvoje> * we introduce a "real" INLINE macro that does the right thing in C Hrvoje> sources. INLINE would expand to `inline' in Gcc (and other Hrvoje> compilers that support inline the same way), `static inline' in C++, Hrvoje> and to nothing otherwise. Careful. There are 4 different compiler behaviors: - no inline support. - gcc historic inline support - C9x standard inline - C++ standard inline There will be a 5th, when gcc decides how to transition from gcc historic inline support to c9x inline support. The way I read it, C9x made the idiotic decision to have the meaning of `extern' used with `inline' have the exact opposite meaning it had with gcc. To add to the confusion, functions with external linkage will behave differently from functions with internal linkage (`static'). All inline implementations have to deal with the fact that inline functions may or may not be expanded inline in any particular source file. Typically this is dependent on the optimization level and whether the optimizer feels up to inlining a given function (famous example: use of alloca() disables inlining in gcc). Therefore non-inline versions of all functions have to be made available in a separate source file (that's inline.c). Actually, the situation for one-file inline functions is much simpler, since you don't have to deal with the required external definition headache. If inline is supported, `static inline' will almost certainly work. And we have configure support specifically for `inline'. Rule: if you have a static function, and you want to provide a special hint for the compiler that this function _really_ should be inlined (e.g if the function is known to be very frequently called), I think you can currently do that _portably_ in the sources like this: static inline .... As for renaming INLINE to INLINE_HEADER, that does seem like a safer name, but I don't think it's worth making this global change now. I'd rather wait for to see what gcc does. So Andy, if you think get_frame_dc is a performance hotspot, do this: static inline HDC get_frame_dc (struct frame *f) Martin