[Top][All Lists]

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

Re: Static inlining in the gl-list module

From: Bruno Haible
Subject: Re: Static inlining in the gl-list module
Date: Tue, 19 May 2009 12:56:50 +0200
User-agent: KMail/1.9.9


David Vazquez wrote:
> I am developer in the GNUPDF project development, where we are using
> some gnulib modules. Recently, we have some troubles with static
> inlining from the gl-list module, with gcc 4.3.2 version. They are
> warnings like:
>    gcc -DHAVE_CONFIG_H -I. -I../lib -I./base -I./object -I./document -Wall 
> -fno-strict-aliasing -g -O2 -MT pdf-hash.lo -MD -MP -MF .deps/pdf-hash.Tpo -c 
> base/pdf-hash.c  -fPIC -DPIC -o .libs/pdf-hash.o
>    In file included from ./base/pdf-hash.h:30,
>                     from base/pdf-hash.c:39:
>    ./base/pdf-list.h: In function 'pdf_list_new':
>    ./base/pdf-list.h:200: warning: 'gl_list_create_empty_inline' is static 
> but used in inline function 'pdf_list_new' which is not static

2 questions:

- What is this warning actually warning about? What can go wrong if an 'extern 
  function uses a 'static inline' function that was defined previously?

- I see the source code of pdf-list.h in
  line 186. It uses a macro EXTERN_INLINE which is defined in
  line 477, in a fishy way (the code is not consistent with the comments).
  To what does EXTERN_INLINE expand in your case?

>    /* Define all functions of this file as inline accesses to the
>       struct gl_list_implementation.  Use #define to avoid a warning
>       because of extern vs. static.  */
> I don't know very well what it means, but using #define to shadow a
> keyword is not desirable.

gnulib is not shadowing a keyword in gl_list.h. It may be shadowing the
'inline' keyword, though, if it does not work (through AC_C_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?


[1] http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Inline.html
[2] http://lists.gnu.org/archive/html/bug-gnulib/2006-11/msg00055.html

reply via email to

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