This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Convert 3.2 sources to ISO C90
- From: Stan Shebs <shebs at apple dot com>
- To: law at redhat dot com
- Cc: Marc Espie <espie at quatramaran dot ens dot fr>, gcc at gcc dot gnu dot org
- Date: Thu, 06 Jun 2002 09:28:56 -0700
- Subject: Re: Convert 3.2 sources to ISO C90
- Organization: Apple Computer, Inc.
- References: <8628.1023372247@porcupine.cygnus.com>
law@redhat.com wrote:
>
> 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?
Does a 1% improvement in compiler codegen matter that much? Not
by itself. You can make the same argument for any style point -
"does putting a space before parens improve the readability of the
code that much?".
> > 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.
But I don't have one, nor do most GCC developers. We basically
have to rely on the handful of HP maintainers to be the oracles
of whether GCC is properly K&R compatible.
> > 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.
OK, so let me get this straight - GCC has to have K&R compat because
Red Hat has customers who are too stingy to spring for acc, but who must
have spent lots of money on a support contract if they're getting onsite
support.
What are you going to do when GCC sources change in some way that
triggers a fatal bug in HP's bundled compiler? Are we all going to
be required to know how to code around that bug?
Is HP really so important that we have to hobble GCC for HP's
convenience?
Stan