Re: Convert 3.2 sources to ISO C90

[law at redhat dot com]

 In message <3CFF5E10.3D440568@apple.com>, Stan Shebs writes:
 > That code would be more readable if you didn't have to have all
 > the PARAMS and the VA_FIXEDARGS and the like, eh?
That stuff is pretty trivial.  Do you think the really affect the
readability of the code that much?


 > But yes, this is a minor issue, just as removing obsolete configs
 > is a minor issue.  To me the main problem with the K&R requirement
 > is that it adds a bunch of programming rules that you can't test for
 > without having an actual K&R compiler (-traditional not being a
 > perfect emulation).  This is very much like the obsolete config
 > situation, where infrastructure changes are easier if there aren't
 > a lot of obsolete broken configs to change.
I don't consider this anything like obsolete configurations.  Obsolete
configurations take a quite a bit more ongoing maintenance as we update
things (particularly moving to a more target-vector like approach) and
old configurations take quite a bit more thought as we change how the
optimizer works.  For example -- who really understands how minor tweaks
to the optimizer is going to affect the convex, or the pyramid, or the
mn102?

 > A couple folks have pointed out that K&R C is not well-specified
 > either, and indeed all the compilers from the K&R era had slightly
 > different behavior.  Since probably nobody bootstraps on SunOS etc
 > anymore, the only thing we really know about GCC's K&R compat is
 > that it can be built with HP's bundled compiler sometimes.  Not
 > a very solid basis on which to write your code!
HP's traditional compiler has always been a good test of avoiding
ANSI features.

 > Again, a minor issue, and I wouldn't even have brought it up if
 > I didn't think that the time and complexity savings justified the
 > small effort of making the transition.
I disagree strongly.  It wasn't that long ago I was on-site with a customer
that had applied a patch from HP which resulted in their copy of GCC being
utterly useless.  In fact, the HP patch made any existing GCC binary from
anywhere utterly useless.   This particular customer didn't have the
unbundled compiler from HP.  Luckily I was able to identify the problems
the HP patch caused, fix the source for GCC, then bootstrap it using HP's
bundled compiler.  If we had ANSI-ified the sources, then we would have been
hosed worse than I care to imagine.


 > > Plust, it's going to divert some people's energy (Jeff) into making
 > > HP-UX work still (and loads of bug-reports I am sure).
 > 
 > It's not at all clear to me that Jeff would have to do anything
 > because of the switch.  In fact, what I've heard so far is that
 > the status quo involves extra work for each release, clearing
 > out ISOisms in the code.
It would certainly require more work for me and cause folks building GCC
on HPs even more problems than they currently face.

The amount of work to clear out ISOisms is trivial (I know because I do it
pretty regularly).  

jeff