From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2292 invoked by alias); 13 Dec 2003 01:01:09 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2205 invoked from network); 13 Dec 2003 01:01:08 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 13 Dec 2003 01:01:08 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 639332B8F; Fri, 12 Dec 2003 20:01:04 -0500 (EST) Message-ID: <3FDA64D0.7020306@gnu.org> Date: Sat, 13 Dec 2003 01:01:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: Eli Zaretskii , drow@mvista.com, gdb-patches@sources.redhat.com Subject: Re: [commit] Deprecate remaining STREQ uses References: <3FC119EB.1060102@gnu.org> <3FC234C0.1000500@gnu.org> <20031124165047.GA2227@nevyn.them.org> <1031124182547.ZM9776@localhost.localdomain> <3FC26407.9000704@gnu.org> <1031125000932.ZM11256@localhost.localdomain> <3FC60A75.8090803@gnu.org> <1031204044404.ZM3660@localhost.localdomain> <9743-Thu04Dec2003174358+0200-eliz@elta.co.il> <3FCF6FCA.30607@gnu.org> <1031212192642.ZM21819@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00346.txt.bz2 > On Dec 4, 12:32pm, Andrew Cagney wrote: > > >> >> If a contributor wants to add new code, or fix bugs in existing code, > >> >>> they should not be increasing the use of existing deprecated mechanisms >> >>> (after all we should be able to reasonably expect contributors to not >> >>> make matters worse). The prime motivator here should our joint goal to >> >>> make GDB the best debgger possible, and more immediatly our desire to >> >>> fix bugs such as those identified by my rewritten structs.exp. As for >> >>> other code, let it bitrot and die. > >> >> >> >> I agree with much of what you say, but I really can't agree with the >> >> last part. There is a quite a lot of code which simply cannot be >> >> allowed to "bitrot and die". > >> >> Kevin's comment here is way over my head. >> >> Firstly we're actively maintaining and improve our code base, as if we >> fail to do this, our code will bitrot and die. This isn't because of >> deprecation, rather its because GDB is part of a rapidly chaning world - >> GCC changes, the OS changes - and each change creates new and wonderful >> requirements while at the same time unearthing old bugs. >> >> An unfortunate consequence of this is that sections of the code base >> will fall by the wayside (if they were sufficiently important one of us >> would have step up and sort out the mess - as mark has done for the >> SPARC). I say let it. We've better things to spend our limited >> resources on such as (as eli observed) adding new features and >> functionality to GDB. >> >> So, to put it simply, what code? > > > Symbol readers (some of them anyway), MIPS architecture, PPC > architecture, to name three. Sorry, I'm again lost. Over the last while I committed more fixes and cleanups to MIPS and PPC - their testsuite failures went down. As for symbol readers, we've not got that many left. Both Michael and Joel are casting an evil eye at HP though. >> >> From: Kevin Buettner >> >> >> >> I have already stated that I think the renaming of deprecated >> >> interfaces is okay in some instances. I am concerned, however, that >> >> this approach is being used in instances where it doesn't really >> >> need to be. > > [...] > >> However, more puzzling is Kevin's generalization that "this approach is >> being used in instances where it really doesn't need to be". It >> strongly implies that STREQ, rather than being the exception, is the >> norm. If if that is the case then more details would be helpful. > > > One (admittedly historic) example is the introduction of the complaint() > interface. As I recall, the old (now removed) interface was called > complain() and a new interface named complaint() was introduced. There > were good reasons for wanting a new interface; as I recall, the new > interface allowed compile time checking of the call's arguments with > respect to a format string whereas the old interface did not. So, > I have no problem with the introduction of the new interface. The > bit that I have a problem with is that calls to the old interface > were left in place after the new interface was introduced. As I recall, > I made a change to dwarf2read.c which used the old interface. I > was immediately admonished to use the new interface. IMO, it's > really ugly to have some code in a source file use an old interface > while other code in the same source file uses the new interface, so I > set out to correct this problem - which I did. But, also IMO, the > person introducing the new interface ought to have done the work of > eliminating the old interface. http://sources.redhat.com/ml/gdb-patches/2002-10/msg00370.html > I suspect that what this boils down to is a difference in maintenance > philosophy: I would prefer to see old (deprecated) interfaces eliminated > as soon as possible even if it does involve touching possible candidates > for deletion, whereas you don't seem to mind having old interfaces > retained for longer periods of time. To make this more concrete, perhaphs you could outline how this would have worked with the old vs new frame code. Andrew