Bruno Haible <br...@clisp.org> writes: > 2 questions: > > - What is this warning actually warning about? What can go wrong if an > 'extern inline' > function uses a 'static inline' function that was defined previously? > > - I see the source code of pdf-list.h in > > <http://bzr.savannah.gnu.org/lh/pdf/libgnupdf/branches/trunk/annotate/head:/src/base/pdf-list.h> > line 186. It uses a macro EXTERN_INLINE which is defined in > > <http://bzr.savannah.gnu.org/lh/pdf/libgnupdf/branches/trunk/annotate/head:/src/base/pdf-types.h> > line 477, in a fishy way (the code is not consistent with the comments). > To what does EXTERN_INLINE expand in your case?
- I don't know either. - EXTERN_INLINE was expanding correctly in both gnu89 and gnu99 gcc modes, by default to extern __inline__. I tried other expansions, but gcc emits warnings anyway except for static inline. >> So, I think a GNULIB_USE_INLINE macro to >> avoid warnings would be more advisable. It could provide the macros >> GNULIB_USE_STATIC_INLINE and GNULIB_USE_EXTERN_INLINE to specify the >> model of inlining too. > > 'static inline' is the only portable use of 'inline' (across ANSI C, C99, > and C++ compilers) [1][2]; therefore gnulib uses only 'static inline' and > avoids the complexities of 'extern inline'. > > In order to share the code definitions for the inlined and for the real > function definition, gnulib uses a particular idiom in xalloc.h and xmalloc.c. > Maybe you can consider this as an alternative to the use of EXTERN_INLINE? > It is right. Finally we will change from extern inline to static inline, because newer gcc versions emit warnings too. Thanks. David
