Using |inline| in X.org codebase / was: Re: Usage of ANSI-C |const| in X11 code...

[Kean Johnston]

>>Well with autotools we can detect this at compile time... ;)
> Yes yes... one point for the autotools... :)
Only 1/2 a point :)

Detecting things at compile time is great if you're working in
isolation, or you can guarantee that your headers / libraries
wont be used anywhere else. Not the case with X11. Just because
the compiler you compiled X11 with supports inline correctly
does not mean that when the headers get installed, that some
other compiler on the system will behave the same way.

>>As with the const keyword, I don't know of _any_ compiler that doesn't support
>>'inline' as a keyword.  Which means I'm perfectly willing to just not worry
>>about it until some poor sucker with an ancient compiler complains.
Depends entirely on how you define "support". Some compilers
treat inline as an optimization hint. If you write code that
*depends* on the code being inserted inline, you're asking
for trouble. Many compilers will simply take inline to mean
"make this code inline unless some other optimization reason
tells me its inefficient to do so".  For eample, if the code
you are inserting inline has common sub-expressions, or
invariants in a loop or any number of such things, you have
no guarantee that the code after the inline will really be
inlined.

> I would prefer if the X.org codebase could be compiled with strict
> ANSI-C89 to gurantee maximum portability. If we let it slip now we may
> end-up in later cleanup work which wouldn't be neccesary if we start to
> use it properly from the beginning.
In that case, what's the *requirement* for inline? Its far less
useful than folks might think. Part of the reason is becuase of
the optimistic way in which GCC treats inline. But thats not what
the standard intended. Quoting the C standard's rationale of
inline:

    Note that it is not appropriate for implementations to provide
    inline definitions of standard library functions in the standard
    headers because this can break some legacy code that redeclares
    standard library functions after including their headers.  The
    inline keyword is intended only to provide users with a portable
    way to suggest inlining of functions.  Because the standard
    headers need not be portable, implementations have other options
    along the lines of:
       #define abs(x) __builtin_abs(x)
    or other non-portable mechanisms for inlining standard library
    functions.

Note the phrase "is intended only to provide users with a portable
way to *SUGGEST* inlining of functions".

Although the X libraries are not part of the "standard C library",
they are nonetheless general purpose enough that a developer may
very well expect to be able to write a replacement function for
some internal X function, perhaps for debugging, after including
the appropriate header.

It's just something to think about before making broad sweeping
changes through the code making all sorts of things inline :)
If the use of inline is restricted to purely internal functions
then its fine. As soon as the API is exported, inline should be
forbidden.

> The alternative is to declare that Xorg trunk requires full ANSI-C99
> compilance (I am not sure whether everone here will be happy with
> that...) ...
C99 is a different beast altogether, and far fewer compiler vendors
have adopted it than are C89 compliant. I think you'd be cutting off
a much larger audience if C99 compliance is made mandatory.

Kean