Re: [commit] Deprecate remaining STREQ uses

Andrew Cagney
2003-12-13T01:01:09Z

> 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 <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.

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