[gnutls-dev] Re: constification patch

[Simon Josefsson]

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.)

/Simon