Usage of ANSI-C |const| in X11 code...

Adam Jackson ajax at nwnk.net
Fri Mar 25 20:49:32 PST 2005


On Friday 25 March 2005 18:59, Roland Mainz wrote:
> AFAIK it depends... some compilers may just modify the calling
> conventions to fit their needs if they can control all the callers, too
> (for example when the compiler has a global view about the whole
> application in the Sun Workshop XIPO case or for |static| functions).

Yes, gcc can do this too, but it's wholly orthogonal to the semantics of the 
'register' keyword, which is only a hint on variable declarations.

> OK... how should the usage of |inline| be handled ? We need 1) a way to
> detect support for |inline| and 2) a convention for what should be done
> if |inline| isn't supported (just doing a |#define inline| isn't
> possible as this may cause trouble with system includes (or better:
> compiler-specific includes) so we either need something like |#ifdef
> SUPPORTS_INLINE\n#define _Xstaticinline static inline\n#else\n#define
> _Xinline static\n#endif| or a different way to guard this stuff... any
> comments/suggestions/ideas ?

Well with autotools we can detect this at compile time... ;)

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.

In other words, naked 'inline' is fine, as far as I'm concerned.

We appear to use both __inline and __inline__ for this, as well as the 
'inline' keywords itself (mi/miarc.c for example).

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050325/d343c7c7/attachment.pgp>


More information about the xorg mailing list