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

[Roland Mainz]

Adam Jackson wrote:
> 
> On Friday 25 March 2005 16:12, Roland Mainz wrote:
> > Adam Jackson wrote:
> > > Can anyone even name a compiler shipped in the last ten years for any
> > > major operating system that didn't include ANSI C support?
> >
> > AFAIK no new operating system (but there are still a couple of companies
> > out there who have to support their old stuff... ,-/)
> 
> Life is hard for those companies.  They should offer free upgrades to their
> customers who are still using compilers older than X itself for having been
> so doggedly loyal all these years.
> 
> Also I hear there's a very good compiler that implements c89 and much of c99
> as well.  It's supported on many platforms, and is even free software:
> 
> http://gcc.gnu.org/
> 
> I think one or two of the X developers might even be using this as their
> primary compiler. ;)

:-)

> If c89 was effectively required in 6.3, as Alan said, then I don't see any
> reason to move backwards.

I didn't say anything of moving backwards, I just tried to express that
we may leave some people behind - but in this special case I don't
care.. :)

> > > It's kind of like the register keyword.  If it makes you feel better, you
> > > can add it to your declarations, but it's really not going to change
> > > anything.
> >
> > AFAIK on some platforms (SPARC comes in mind) it makes a huge difference
> > as values are passed in registers (unless all registers are used up) and
> > not via the stack (and no stack version is provided).
> 
> Yes, this is true on x86 too.  However the register keyword has nothing to do
> with function calling conventions.

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

> > > If we find performance-critical code where inlining makes a difference
> > > for a given compiler, we should handle that case-by-case, because
> > > heuristics differ and what's fast in gcc may be slow in sun c.
> >
> > My point with using |inline| was more to replace some of the very ugly
> > #define macros with |inline| functions (|static inline| to be exactly)
> > to give the compiler better ways for type checking, the optimizer a way
> > to analyse (e.g. profiling) the code correctly (I am looking here at Sun
> > Workshop's XIPO option which allows the optimizer to operate application
> > wide in one step (e.g. the optimizer can inline&&optimize over all
> > source files in one step (which gives nice performance boosts when this
> > step is combined with profile-feedback))) and make the code more
> > readable, too.
> 
> That sounds reasonable.

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 ?

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)