[FFmpeg-cvslog] r9547 - in trunk/libavcodec: cavs.h h264.c mpegvideo.h snow.c

[Uoti Urpala]

On Mon, 2007-07-09 at 02:10 +0100, M?ns Rullg?rd wrote:
> So what do we do with this function?  Make it "extern inline"?  Move
> it to a header as "static inline"?

The problem is that in gcc versions prior to 4.3 the meanings of
"inline" and "extern inline" are inverted which means it's hard to write
code that would both conform to the standard and work under those gcc
versions.

Using "extern inline" in a header would make no sense under C99 (every
translation unit defines the global symbol?).

If the header uses "inline" at all then it must contain a definition of
the function (unless you require each file including the header to
contain its own definition).

I think the way it was before you changed it was correct C and worked
under gcc too. The declaration in the header was not inline and was
visible in mpegvideo.c, thus the C standard implied that mpegvideo.c
creates a global symbol. gcc also generated a global symbol because the
definition was not "extern inline" (in standard C an extern declaration
and an "inline" declaration mean the same as "extern inline", but under
gcc they do not mean its version of "extern inline"). There was no
"inline" specifier visible in any other files so they used the global
definition without inlining. If you want to get rid of the "declared
inline after being called" warning in gcc you can either move the inline
function definition before the calling function or add another prototype
with "inline" in the .c file.

If you want to make the function inline in other translation units too
then you need to move it to the header, and either 1) make it "static
inline", or 2) make the definition in the header "inline" and include an
extern declaration in one .c file to create the global symbol there (but
in this case the gcc behavior causes problems).