[gnutls-dev] Re: constification patch

Simon Josefsson jas at extundo.com
Tue Apr 4 14:27:54 CEST 2006

bryanh at giraffe-data.com (Bryan Henderson) writes:

> I've spent some time investigating the issue of "inline" keywords in
> portable code.  For those who haven't had the pleasure:
> First of all, the "inline" keyword rarely affects speed.  Why?
> Because a modern compiler inlines on its own when it helps.  (And if
> you disable optimization, many will _not_ inline even if you use the
> keyword).  Some compilers actually ignore the "inline" keyword
> completely, and others don't have one.
> So no one should be afraid to take some lines out of the middle of a
> function and make it a separate function for readability, out of fear
> that the subroutine call will take too long.  And functions should be
> used instead of macros where possible because they're a lot easier to
> read and debug and the compiler can type-check arguments.
> The main reason for "inline" these days is to avoid a warning that
> you've defined a function and not used it (because when you put a
> static function in a header file, many programs that include that
> header file won't use it).
> Compilers variously have "inline", "__inline", "__inline__", and
> nothing at all.  "__inline" and "__inline__" are sometimes macros and
> sometimes native keywords.
> The best thing to do is to put a mess of ifdefs in a central file that
> define __inline__ as the appropriate keyword or undefined, and use
> __inline__ in functions that are defined in header files.  I don't
> know GNU Autoconf, but I presume it provides a service to help with
> that.

Right, there is AC_C_INLINE which should #define 'inline' to some
suitable string for each compiler, or nothing at all if the compiler
doesn't support it.  GnuTLS uses it.

(Sorry for the slow response.)


More information about the Gnutls-devel mailing list