Re: More Objective C @"string" bugs...

[Ovidiu Predescu <ovidiu at cup dot hp dot com>]

Well Nicola, I think the basic problem comes from the fact that some
of the GCC maintainers are volunteers to the project, and they do this
work in their spare time. You can't stop the active developers from
doing work that radically changes the compiler just because it will
affect portions of the compiler that are not actively developed. I
personally think the approach that has been taken to do changes and
worry about the implications in the other portions of the code later,
is correct.

In the particular case of the Objective-C front-end, as a maintainer I
don't even do Objective-C work anymore, so it's even harder to test
all the recent changes in GCC on real Objective-C code.

Personally I would love to see somebody else take over the Objective-C
maintenance. I even found a volunteer in the person of Stan Shebs of
Apple, who's responsible for the Apple's Objective-C compiler. I sent
several messages to Jeff Law about this in the last few months, but
got no reply. Who should I contact to have this reassignment done?

Regards,
Ovidiu

On Tue, 6 Mar 2001 05:03:34 +0100 (CET), Nicola Pero <n.pero@mi.flashnet.it> wrote:

> 
> > It looks like no one updated the ObjC front end for this change:
> 
> I wonder if it was not the responsibility of the person who made the
> change to update it.  Or - at least - he should have warned people working
> on other front ends (other than C/C++) that they needed to update their
> front ends, and how.
> 
> rest_of_decl_compilation is used in all front ends I have (C, C++,
> Objective-C, fortran, java), and presumably in all front ends I don't have
> as well.
> 
> I wonder what a nightmare it should be to write and maintain a gcc front
> end for a language, if it would be broken that way, that hard, and that
> silently - and that routinely.  A random anonymous entry in the ChangeLog
> (one in thousands) - no notice on mailing lists - and zack! - a radical
> change was made - your front end still compiles - but in reality it is
> broken - subtle bugs are creeping in - now you can happily spend your next
> two days/weeks/months figuring out that your front end is buggy - and
> where - and why.
> 
> And I have some notice of this nightmare by looking at the fact that a
> perfectly working front end (Objective-C) - kept on the gcc cvs
> repository, with a stable maintainer and a big userbase - has been reduced
> to a pathetic state by careless gcc hackers in less than one year.  Such a
> pathetic state that nobody is using it (not even for testing), and
> everyone is still using gcc-2.95 to compile Objective-C.
> 
> Are people writing frontends supposed to spend their days reading all the
> commits to gcc, figure out what was changed in each of them, and update
> all their code ?  That means you spend all of your time just to keep your
> existing code to work.
> 
> Wouldn't it be simpler if the person who makes a change in the core of gcc
> - which could break frontends - updates the frontends kept in the gcc
> repository and informs external developers that they need to update
> theirs, and how ?  I know this adds quite a overhead for the core gcc
> hackers - all quality procedures adds a certain overhead - but what relief
> for front ends.
> 
> As a newcomer to gcc development, the fact that an existing working
> frontend (correct code!) is broken silently and randomly by gcc core
> development commits seems to me a wicked combination of ugly program
> design and - particularly in the case of frontends which are kept in the
> gcc repository - very bad habits of some gcc hackers who don't take into
> account the existence and importance of front ends different from C/C++.
> 
> 
> > 2001-02-26  Jason Merrill  <jason@redhat.com>
> > 
> >         * c-decl.c (finish_decl): Set DECL_DEFER_OUTPUT on tentative file-scope
> >         definitions.
> >         * toplev.c (rest_of_decl_compilation): Check DECL_DEFER_OUTPUT to
> >         recognize a tentative definition.  Lose obsolete code.
> > 
> >         * toplev.c (wrapup_global_declarations): Don't emit DECL_COMDAT
> >         variables unless necessary, either.
> > 
> > objc-act.c is assuming it's safe to call rest_of_decl_compilation on a
> > half-initialized decl and then set its constructor, which is no longer
> > true.  The appended patch makes my test program compile and run
> > successfully.  I've also changed the existing string[12].m so that
> > they don't mask the bug anymore.
> 
> 
>