This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: Support for Pascal strings -- Take 2


"Joseph S. Myers" wrote:
> 
> On Tue, 3 Jul 2001, Stan Shebs wrote:
> 
> > The truth of the matter is that all the discussion and rewriting
> > of this patch has already well exceeded the time that has gone into
> > maintaining it in Apple's GCC over the past several years.  Since
> 
> I'd hope you'd want to end up with any and all patches that stay in
> Apple's GCC and do not go in the FSF GCC being clean (in implementation,
> if not in the semantics of the extension they implement), self-contained,
> and with proper documentation and testcases - so while improving patches
> not intended for FSF GCC is not the purpose of the GCC lists, if a patch
> intended for FSF GCC ends up not going in FSF GCC, the improvements to it
> ought still to be found useful.

Yes and no.  At the risk of drawing down righteous-sounding flamage on
my head, I'll say that engineering is all about achieving a result while
working within a given set of constraints, whether they be time, money,
physics, etc.  For software, time is our most important constraint; a
beautiful program is a failure if it's delivered when the user no longer
needs it.  Since Apple depends on GCC to build the main operating system
for its machines, we're always under pressure to deal with one problem
or another by a certain date, and we also have lists of problem priorities
that tell us which to work on first if there's not enough time to do
everything.

This set of pressures runs counter to the FSF GCC development process,
where it's OK to take a very long time to get something just right.
Red Hat folks are caught in this bind too, which is why you often hear
of changes they've shipped to customers but that are not contributed to
FSF GCC.  I suspect you'll find that almost everybody who's getting
paid to work on GCC is continually having to think about how much effort
they can afford to sink into each patch.

To take Pascal strings as an example, Apple's developers have always
been happy with an underspecified, untested implementation.  It was a
bit of a risk, in that somebody might need one of the edge cases to work
also, but if there are reasonable odds that it would never happen, then
you're ahead if you postpone the work until somebody actually runs into
the edge case.  Indeed, there are obscure locations throughout FSF GCC
where a problem wasn't worth trying to solve at the time, and there is
only a comment observing the omission.

So is it useful to have a patch be improved?  Sure.  Is the time and
expense justified?  In the Pascal strings case, perhaps not.  The
number one complaint from our users is that GCC runs too slowly, and
the number two complaint is that its output is poor compared to other
Mac compilers.  Fiddling around with Pascal strings is motivated by a
desire to work more closely with other GCC developers, which is an
investment in the future, because we believe that working together
is more likely to satisfy our users' desires in the long run than
working on GCC separately.

> (I don't know, though, how at present
> your patches to FSF GCC are maintained and distinguished from each other
> and from unmodified FSF code, and to what extent they are already properly
> documented or have testcases.)

There are comments with a distinctive string ("APPLE LOCAL") and some
additional info.  The quality of documentation and testcase is variable;
for instance, AltiVec support defines well over 100 builtins, but there
aren't tests for each of them.  (One might say that's in keeping with FSF
tradition, since there aren't testcases for any of the target-specific
builtins for other targets :-) )

Stan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]