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

[Måns Rullgård]

Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:

> On Mon, 2007-07-09 at 00:46 +0100, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> >> -int ff_h263_round_chroma(int x);
>> >> +inline int ff_h263_round_chroma(int x);
>> >>  void ff_h263_encode_motion(MpegEncContext * s, int val, int f_code);
>> >
>> > hides warning doesnt fix gnuism inlining
>> 
>> What's gnu about it?  Some *non*-gnu compilers can actually inline
>> functions across files...
>
> Current gcc doesn't implement "inline" for non-static functions
> correctly. The standard says:
>
> -----
> If all of the file scope declarations for a function in a translation
> unit include the 'inline' function specifier without 'extern', then the
> definition is an /inline definition/. An inline definition does not
> provide an external definition for the function, and does not forbid an
> external definition in another translation unit. An inline definition
> provides an alternative to an external definition, which a translator
> may use to implement any call to the function in the same translation
> unit.
> -----
>
> For a global function there should be exactly one translation unit which
> provides an external definition for the function. After your changes
> mpegvideo.c is the only translation unit to contain an implementation
> for the function, and it's inline without extern thus does not provide
> an external definition. So using the function from other translation
> units is impossible under a C99-conforming compiler.

So what do we do with this function?  Make it "extern inline"?  Move
it to a header as "static inline"?

-- 
M?ns Rullg?rd
mans at mansr.com