Rename attribs.c to attributes.c

Basile Starynkevitch basile@starynkevitch.net
Wed Jun 22 19:56:00 GMT 2011


On Wed, 22 Jun 2011 20:36:21 +0200 (CEST)
"Nicola Pero" <nicola.pero@meta-innovation.com> wrote:

> > Huh, I see no reason for this rename.  It'll just make patches across
> > releases harder.
> 
> Sure.  But any change will make "patches across releases harder" ... does
> it mean we can't make any changes - not even in phase 1 ? :-(
> 
> The reason I'd like to change the name is that "attribs.c" is meaningless.
> I never realized it contained code to deal with attributes until I opened
> the file and read the code inside.  I always thought it contained some
> sort of mysterious internal GCC data structure or pass.  Isn't that a good
> enough reason to rename it ? :-)


I agree with such renames and clean-ups, but I also sadly think there
are very difficult in the GCC community (because old-timers who could
approve that don't care, and don't like such patches).

In an ideal world, I would like many patches like this. In particular,
I would like some consistent naming conventions (that would contribute
to define what modules are in GCC - so far, we do have "modularity
efforts", but I still believe that we don't have yet modules: we cannot
name them, and we cannot even count them, so in my view they don't
exist yet; some nice old-timers have been upset because I told that GCC
is not modular, but since GCC modules are not counted nor named yet, I
still believe that GCC is not made of well defined modules - and that
is what I mean by "modularity"; for many GCC gurus, it is only a
relative qualification -unrelated to any set of modules-, and GCC is
indeed slowly improving in that aspect.).

An example of patches I dream about but would never dare submitting is
a patch consistently renaming every GCC optimization pass (of struct
opt_pass type, or its subtype). I feel that it would help a lot new
people (and even me) if consistently every pass whose name field is
"FOO" is named FOO_pass (or pass_FOO, I don't care about what
convention we use provided we use it consistently & systematically).
And for the same reasons your patch renaming "attribs.c" to
"attributes.c" is rejected, I believe such a patch (renaming
consistently passes) would also be rejected. It is very sad.

Many GCC gurus don't see the point to make GCC code easier to read to
newcomers (since such a change would temporarily make GCC code harder
to read & to patch for them). This is sad, but won't change. 

As a counter example, I do find GTK (& related libraries) a lot more
modular and more readable than GCC code - both coded in C; naming
conventions, separation of modules as different libraries, usability as
a library, documentation generated from code, younger age.... explain a
lot.

But GCC is too big and too important (and probably working well enough)
to change a lot. So while I do welcome a lot patches like the changing
of attribs.c to attributes.c advocated by Nicola Pero (and I admire his
courage), I sadly believe they won't happen (unless proposed by a very
select & closed circle of people).

Perhaps the long term goal of progressively rewrite GCC in C++ might
help (but I am a bit skeptical here too, I don't see lot of code on
this point.). I don't like C++, but I believe that it could perhaps
push such a rewrite (but I am pessimistic on the short run).

There is an economical explanation for this: no corporation (not even
the richest ones like Google, IBM, ...) is willing to spend money
paying GCC developers to re-factor or rewrite parts of GCC. And such a
massive effort won't happen freely (i.e. without investment). Besides,
some organizations or people knowing very well GCC have no interest in
such changes.  And indeed, few people could promise that such a
rewriting would improve GCC by a significant, predictable, & measurable
amount.  Sadly, GCC is almost nearly good enough for most corporations
investing in it (so they can invest only in "marginal" improvements,
even if "marginal" may mean several person-years to them!).

Cheers.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***



More information about the Gcc-patches mailing list