[FFmpeg-devel] Fwd: [PATCH] Support alternative spellings of the inline keyword.

[Ronald S. Bultje]

Hi,

On Sat, Jun 16, 2012 at 7:08 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> Hi
>
> On Sat, Jun 16, 2012 at 06:05:03PM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> same here, part of a MSVC port.
>>
>> Ronald
>>
>> ---------- Forwarded message ----------
>> From: Ronald S. Bultje <rsbultje at gmail.com>
>> Date: Fri, Jun 15, 2012 at 7:04 PM
>> Subject: [PATCH] Support alternative spellings of the inline keyword.
>> To: libav-devel at libav.org
>> Cc: "Ronald S. Bultje" <rsbultje at gmail.com>
>>
>>
>> From: "Ronald S. Bultje" <rsbultje at gmail.com>
>>
>> This is similar to how we support e.g. __restrict as an alternative for
>> restrict, and allows us to support compilers that use __inline instead
>> of inline. The define is placed in avconfig.h instead of config.h since
>> we use inline in public header files.
>
> [...]
>>  #ifndef AVUTIL_AVCONFIG_H
>>  #define AVUTIL_AVCONFIG_H
>> +#define inline $_inline
>>  EOF
>
> Is this safe if ffmpeg is compiled and installed with one compiler
> and an application with a different compiler ?
>
> I mean configure is run with one compiler but a application that may
> include the header and thus #define inline (__)inline could use a
> different compiler.

No, that would break. A solution for that would be to statically
define inline in one of the main headers (similar to how attributes.h
is set up) depending on the compiler, i.e.:

#ifdef _MSC_VER
#define inline __inline
#endif

I'm not sure why I didn't put this in attributes, but I can move it
there, I don't particularly care where it goes, as long as it's
available for use in installed headers, since we use inline all over
the place in installed headers.

Also, if we're scared of symbol collision, we could even rename to
av_inline, but I'd prefer not to since that's a lot of sed left to do.

Ronald