[PATCH:xscope 04/24] Convert some for loops to use C99-style inline variable declarations

[Matthieu Herrb]

On Sat, Sep 01, 2012 at 10:21:14AM -0700, Alan Coopersmith wrote:
> On 09/ 1/12 03:33 AM, Mark Kettenis wrote:
> >> From: Alan Coopersmith <alan.coopersmith at oracle.com>
> >> Date: Fri, 31 Aug 2012 22:17:46 -0700
> > 
> > Please don't do this.  Some OpenBSD platforms are still stuck with GCC
> > 2.95.3.  GCC 2.95.3 is almost a C99 compiler, but doesn't support the
> > C99 (mis)feature of allowing variable declarations after statements.
> > That's always been a controversial feature, although using it to
> > declare loop variables inside a for statement like you're doing here
> > is fairly widely accepted.
> 
> I admit part of my intent with this patch was finding out if it would cause
> problems in X.Org code, in a much less critical area than the core X server.
> 
> I do wonder though about the viability of updating some parts of your system
> to 2012 releases while keeping others stuck at a 2001 release.   I certainly
> don't try to build current X.Org releases on Solaris 8 with our Studio 8
> compilers and wouldn't expect anyone else to put in effort to do so.
> 
> We're not going to stay gcc 2.95 compatible forever, especially since few of
> the rest of us have copies handy to check which subsets it was compatible with
>  - it's just a question of how long.   Is work happening on moving to another
> compiler such as clang?   Is every software package in the open source universe
> holding back for these platforms?   Or are they just being increasingly deprecated?
> 

Honestly, Mark, I don't agree with you on this, especially for xscope,
which is not even packaged in OpenBSD.

Currently the base X libs still build fine on gcc 2.95 (we
have a few local patches for that, but they are small and easy to
maintain) and so it's not too much burden to continue supporting X on
those architectures.

But I consider that as a potential loss of time, and I'm ready to drop
X support for OpenBSD on those as soon as it become too much work
compared to the possible benefits (ie if someone decides to rewrite
large parts of libs required to build xterm with gcc 2.95.

There is no pratical use of X applications on those platforms, except
the checking that the code is really portable. But I don't think that
vax, m68k and m88k (the 3 concerned architectures) bring in much
additional testing, compared to the other atchitectures supported by
OpenBSD. (sparc64 and macppc are the ones that bring the most
diversity nowadays). Vax's non IEEE FP may be interesting, but... it's
vax only.

-- 
Matthieu Herrb