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]
Other format: [Raw text]

Re: [RFC]: designing customizable format attributes


On Sat, 9 Jul 2005, Kaveh R. Ghazi wrote:

> You keep talking in the third person, as if you're speaking for the
> masses.  Realistically, most people don't care about extensible format
> checking and will skip threads they have no interest in.  What you
> really mean is it takes time away from you since you've appointed
> yourself as arbitor of what's "problematic" with this feature.  But
> you can't be an obstructionist simply because you have strong opinions
> about something but you personally don't want to deal with it.

I'd be happy to deal with discussions of features of interest within a few 
GCC-development-days after posting - where GCC-development-days exclude 
days within stage 3.  For the purposes of discussion latencies I think 
stage 3 should be considered to take zero time.

In this case I *also* think that discussions would be liable just to be a 
time-sink at any time whatever: that this is just one of those features 
that seems nice in principle but long-term would be too much trouble to 
maintain in practice.  If the syntax is capable of representing all the 
standard formats (including ones we might want to support as standard in 
future) you probably end up with something Turing-complete and I don't 
think another Turing-complete compile-time feature is desirable.  If it 
isn't capable of representing all the standard formats you end up with two 
different ways in which format checking is set up and handled - the 
hardcoded tables and special cases and some more restricted system for 
user-defined formats - itself probably a cause of bugs and complexity, and 
of the syntax expanding and getting more irregular as special cases are 
added to it.

GCC is free software.  Users are free to patch it for their purposes.  We 
should be willing to encourage doing so where appropriate rather than 
putting features likely to cause maintainability trouble into the FSF 
codebase.  Many GCC distributors have features in various trees which are 
of use to particular users but not suitable for FSF mainline.  If users 
want to check special format types, they always have the option of 
patching GCC to implement their types (or of using external checking 
software; look at how the Linux kernel uses "sparse" to check many 
different static properties of source code; GCC does not need to do every 
sort of checking possible).  Patching GCC and maintaining patches isn't as 
easy as it might be, but more general mechanisms for plugging in GCC 
customisations are another area where discussions are hopeless.

> This is complete hypocrisy.  You took it upon yourself to rewrite the
> C and Objc parsers during the last stage3 and posted multiple huge
> patches over the course of months with discussions ensuing.  The fact
> that C had already been "designed" doesn't lessen the fact that you
> distracted "hundreds of others" instead of waiting until stage1
> several months later to begin soliciting comments.

My hand was forced there by the developments going on with GOMP which 
seemed likely to lead to much more trouble with parsers being written with 
subtle problems (unnecessarily tied to other changes, not designed to 
implement the same language with the same actions as the old parser, or 
not capturing all the subtleties of what the language was) if I didn't sit 
down and write one designed as a minimal incremental change.  It's not 
something I'd wanted to do then without the pressure from the other 
developments happening during stage 3.  This is another example of the 
problematic feedback: developments which might apparently work but have 
subtle problems or aren't designed for verification of lack of such 
problems exert their own pressure to go in because they apparently work, 
and the only effective answer is an alternative implementation which 
avoids the problems.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)


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