Re: Patch: Remove gcc dependency in definition of inline functions

On 1/17/2010 11:27 AM, Peter Eisentraut wrote:
> I have found an Autoconf macro that checks whether the compiler properly
> supports C99 inline semantics. This would allow us to replace the
> __GNUC__ conditional with HAVE_C99_INLINE, in this case.

At present, PostgreSQL uses only "static inline", where
"inline" might be mapped to empty or to an alternate spelling
via a #define generated by autoconf's AC_C_INLINE macro.

static inline functions seem to work the same (modulo spelling
and warnings) across many extended C89 compilers, including
gcc and MSVC. The already existing de facto standard has been
adopted into standard C++ and C99. Consequently, more
implementations will converge toward standard "static inline"
support.

However, C99 introduces its own new rules for functions that
are declared as inline but not static. There was never a widely
accepted de facto standard for non-static inlines. Thus, older
non-static inline functions typically require source changes in
order to upgrade to C99. Because of this source-level upward
incompatibility, compilers might activate the new rules only
when compiling in C99 mode.

Under the C99 non-static inline rules, the programmer provides
an out-of-line definition which the compiler can call anytime
it decides not to use the inline definition. A compiler might
implicitly generate an out-of-line instantiation of a static
inline function in every compilation unit where the definition
is seen; but by using the C99 non-static inline feature, the
programmer can prevent the implicit generation of out-of-line
copies of the function. This is essentially an optimization
done manually by the programmer instead of automatically by
the compiler or linker.

Do we have any need for C99 non-static inlines?

I think we'll be alright if we continue to declare all of our
inline functions as static. Multiple implicit out-of-line
instantiations are unlikely to be a problem because:

- typical inline functions are so simple that they'll always
be generated inline - e.g. list_head()

- compilers commonly don't generate code for a static
function unless the compilation unit contains a call
to the function

- linkers typically delete functions that are not externally
visible and are not called

- linkers may eliminate duplicate sections

- typical inline functions are so small that any remaining
extra copies don't matter

At present, IMO, we don't need full C99 inline semantics.
The widely supported de facto standard "static inline"
semantics, checked by the existing AC_C_INLINE test, are
good enough, or nearly so.

To safely expand the use of inline functions in header files
across a wider set of platforms, we merely need to protect
against unwanted warnings from compilation units which don't
actually call all of the static inline functions defined in
their included headers.

Regards,
... kurt