Re: Static inlining in the gl-list module

[Bruno Haible]

Hello,

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

>    /* 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
> 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?

Bruno

[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