[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Static inlining in the gl-list module

From: David Vazquez
Subject: Re: Static inlining in the gl-list module
Date: Tue, 19 May 2009 19:52:37 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

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
>> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]