inline functions are defined by the ISO C99 and C++ standards, but not
ISO C89 or C90. GNU89 is the default mode for GCC and means (quoting
from the manual): "ISO C90 plus GNU extensions (including some C99
features)". Now those C99 features include the 'inline' keyword, so it
should work, however the extensions are switched off is -ansi is used.

When the -ansi switch is used the _inline_ keyword works as an
extension (the ISO standard allows compiler extensions indicated by the
double-underscore prefix).

It is always a good idea to actually post your build log - then we can
see the exact message you see and how you invoked the compiler - usually
quicker than educated (or sometimes wild) guesses. For example it is not
clear whether this is an warning or error message. I am using 4.1.1 so
am not in a position to verify your observation, but that would not be
possible in any case without knowing what compiler options you used.

Of course you could always just read the manual! ;-)
http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/C-Dialect-Options.html#C-Dialect-Options

I suggest that you use -std=c99 and remove any -ansi switch.

Clifford

The advice I posted above is probably inaccurate. I looked into this
further. Inline functions in GCC 4.2 (and all previous versions) do not
match C99 semantics. I guess in this version they decided to make this
explicit with a warning. C99 compliance is planned for 4.3. Again from
the manual:
http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Inline.html#Inline

In other words it always only ever applied GNU89 semantics but now it is
warning you about it.

I assume that using _inline_ will not generate a warning since as a
GNU extension keyword it makes no promises about C99 compliance. Of
course it may not then port to non-GNU compilers, but a simple macro
could fix that.

The issue is that inline code can only be in-lined by GCC 4.2 and
earlier if it is defined in the same compilation unit in which it is
called. To share inline code between compilation units requires a
two-way cooperation between the linker and the compiler. The only
solution for inter-module inlining is to place the inline code in a
header.

Note that in-lining only occurs when optimisation is used, and even then
the optimiser may choose to ignore the request, and even inline
functions you did not request to inline. You have to use
__attribute__((always_inline)); to force in-lining regardless.

I would suggest that you not try to second-guess the optimiser and just
let it do its job by removing inline requests. Then the problem also
goes away. ;-)

Clifford

Heh! :-/ I should take my own advice and read the manual!

The option -fgnu89-inline explicitly disables the warning. In 4.3 it
will also force GNU89 inline semantics, until then you get no choice in
any case.

Sorry if I have added to your confusion.

Clifford