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

[Adam Jackson]

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.

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

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

- 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/3f5a44b0/attachment.pgp>