Re: Static inlining in the gl-list module

[David Vazquez]

Bruno Haible <address@hidden> 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