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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
