[gnutls-dev] Re: constification patch

[Bryan Henderson]

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.

-- 
Bryan Henderson                                    Phone 408-621-2000
San Jose, California