[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: _GL_INLINE issue
From: |
Bruno Haible |
Subject: |
Re: _GL_INLINE issue |
Date: |
Fri, 13 Apr 2018 22:33:04 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-119-generic; KDE/5.18.0; x86_64; ; ) |
Paul Eggert wrote:
> > what was the motivation of changing
> > 'static inline' to 'static' - other than "it's not needed"
>
> Partly so that the relevant modules wouldn't require AC_C_INLINE.
This is a bit backwards: In gnulib, we usually write the C code first,
and then put together the .m4 file and the module description so that
it fits with the C code. Not the other way around.
> I wanted to work around issues when gcc -fno-inline was used.
> This was during the reorganization when we got Gnulib to work
> better with extern inline and C11.
OK, so I guess this is not a sufficient reason for eliminating all current
and future uses of 'static inline', from dfa.c to regexec.c.
Ben Pfaff wrote:
> For functions defined in .c files, I like to avoid "static inline"
> because "inline" prevents the compiler from warning me when a function
> is unused, which I often find to be a useful warning.
Good point.
And debuggability with gdb. Single-stepping through inline functions is
quite confusing. On the other hand, for debugging, I most often compile
with "-O0 -ggdb" anyway, which inhibits the inlining even of 'static inline'
functions.
Bruno