[commit] Deprecate remaining STREQ uses

[Andrew Cagney]

>> Date: Wed, 3 Dec 2003 21:44:04 -0700
>> 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?

>> 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.
> 
> 
> Seconded.
> 
> Can we conclude this thread by agreeing that renaming of deprecated
> interfaces should be discussed first in cases such as STREQ?  I think 
> everybody agreed on that at some point.

To speak generally, what happens is:

- an interface is identified as a deprecate candidate
See "deprecate" in the ari for a candidate list - most are macros but 
others are cases where the code could do with a refactoring.

- the deprecate candidate gets reviewed, replaced or rewritten
It is at this point that the issue is raised publically, problems in the 
old iterface identified and discussed, and the issue resolved.  Any old 
interfaces get identified as obsolete, ready for the final phase ...

- the now obsolete interface and mechanism get explicitly deprecated
(or removed, depending on how risky it is)

(Of course there are variations on a theme - sometimes the old interface 
is deprecated first as that makes the introduction of the new interface 
easier.)

So there is already a point at which this deprecate can be discussed.

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.

Andrew