Re: [commit] Deprecate remaining STREQ uses

[Kevin Buettner <kevinb at redhat dot com>]

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.

> >> From: Kevin Buettner <kevinb@redhat.com>
> >> 
> >> 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.

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.

Kevin