Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [commit] Deprecate remaining STREQ uses
Date: Mon, 24 Nov 2003 16:50:00 -0000	[thread overview]
Message-ID: <20031124165047.GA2227@nevyn.them.org> (raw)
In-Reply-To: <3FC234C0.1000500@gnu.org>

On Mon, Nov 24, 2003 at 11:41:36AM -0500, Andrew Cagney wrote:
> >Date: Sun, 23 Nov 2003 15:34:51 -0500
> >>From: Andrew Cagney <cagney@gnu.org>
> >>
> >>This patch deprecates remaining STREQ and STREQ uses.  These are the
> >>ones that weren't covered by my testing GDB on a stabs system.  It is
> >>worth noting that the bulk occure in language specific files - this
> >>suggests an area that needs improved testsuite coverage.
> >
> >
> >Sorry, I don't get the rationale for renaming STR* into
> >DEPRECATED_STR*.  Are we going to throw away the code that used
> >STREQN/STREQ?  If not, I don't see any good reasons to do this, as
> >renaming the macro doesn't get us any closer to the goal of replacing
> >them with a simple call to the appropriate str* function.
> >
> >Could you please explain why the renaming is a good idea?


> Note that I'm renaming the _remaining_ STR*s and not all references.  I 
> previously went through GDB's source code and replaced every occurance 
> of STREQ* that is covered(1) by GDB's testsuite (or was in #ifdef 0 
> code).  Since the before/after results were identical, I'm pretty sure 
> those changes were ok.
> 
> Unfortunatly that still leaves GDB containing a notable number of STREQ 
> references:
...
> While I could blindly transform those remaining references, such an 
> operation would be untested and consequently runs the very real risk of 
> introducing bugs (remember my test run didn't cover them).  Consequently 
> they've been deprecated.

Thank you for the details, Andrew, but you haven't answered Eli's
question.  The answer to his question lies in the leap between "blindly
transform" and "Consequently" - why not just _leave_ them? 
DEPRECATED_STREQ is not an improvement over STREQ except for making
things uglier.  We've even got the ARI to remind us; what you've
accomplished is shrinking the STREQ/STREQN column to zero at the
expense of raising the deprecated column even higher.  If that was all
you wanted you could have done it in the ARI scripts.

You've been pushing very hard to renaming things to deprecated_foo for
a while now.  I think I'm not the only other maintainer who doesn't
understand or approve.  It's a lot of work for you; it generates large
patches and source churn; it causes patch rejects and merge errors for
other developers; and the rest of us don't see or agree on the benefit.
Isn't that the sort of thing which should be discussed instead of
implemented?

Or am I out in a corner by myself here?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


  reply	other threads:[~2003-11-24 16:50 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-23 21:08 Andrew Cagney
2003-11-24  5:57 ` Eli Zaretskii
2003-11-24 16:41   ` Andrew Cagney
2003-11-24 16:50     ` Daniel Jacobowitz [this message]
2003-11-24 18:02       ` David Carlton
2003-11-24 19:36         ` Eli Zaretskii
2003-11-24 18:25       ` Kevin Buettner
2003-11-24 20:03         ` Andrew Cagney
2003-11-25  0:09           ` Kevin Buettner
2003-11-27 14:30             ` Andrew Cagney
2003-11-27 17:27               ` Eli Zaretskii
2003-12-01 15:47                 ` Andrew Cagney
2003-12-01 19:08                   ` Eli Zaretskii
2003-12-01 19:17                     ` Daniel Jacobowitz
2003-12-01 19:22                       ` Joel Brobecker
2003-12-01 21:25                       ` Andrew Cagney
2003-12-01 21:32                         ` Daniel Jacobowitz
2003-12-03  3:47                           ` Andrew Cagney
2003-12-03 16:37                             ` Andrew Cagney
2003-12-01 19:40                     ` Andrew Cagney
2003-12-04  4:44               ` Kevin Buettner
2003-12-04 15:45                 ` Eli Zaretskii
2003-12-04 17:33                   ` Andrew Cagney
2003-12-05 16:14                     ` Eli Zaretskii
2003-12-12 19:26                     ` Kevin Buettner
2003-12-13  1:01                       ` Andrew Cagney
2003-11-24 20:32         ` Andrew Cagney
2003-11-24 23:56           ` Kevin Buettner
2003-11-25  1:33             ` Andrew Cagney
2003-11-25  6:51               ` Eli Zaretskii
2003-12-04  4:21               ` Kevin Buettner
2003-11-24 19:33       ` Eli Zaretskii
2003-11-24 19:58         ` Andrew Cagney
2003-11-24 21:06           ` Joel Brobecker
2003-11-26 20:54             ` Andrew Cagney
2003-11-25  6:56           ` Eli Zaretskii
2003-11-24 19:36       ` Andrew Cagney
2003-11-24 20:54         ` Daniel Jacobowitz
2003-11-24 22:08           ` Andrew Cagney
2003-11-24 19:24     ` Eli Zaretskii
2003-11-24 19:45       ` Andrew Cagney
2003-11-25  6:58         ` Eli Zaretskii
2003-11-24 20:06       ` David Carlton
2003-11-25  6:54         ` Eli Zaretskii
2003-11-25 16:59           ` David Carlton
2003-11-25 17:54             ` Andrew Cagney
2003-11-25 17:57               ` Daniel Jacobowitz
2003-11-25 17:59                 ` David Carlton
2003-11-25 18:42                 ` Andrew Cagney
2003-11-25 19:21                   ` Eli Zaretskii
2003-11-25 17:58               ` David Carlton
2003-11-25 18:02               ` Kevin Buettner
2003-11-25 19:14               ` Eli Zaretskii
2003-12-05 16:26           ` Andrew Cagney
2003-12-05 17:56             ` Eli Zaretskii
2003-12-06 14:09               ` Andrew Cagney
2003-12-06 15:23                 ` Eli Zaretskii
2003-12-07 15:54                   ` Andrew Cagney
2003-11-24 17:48 Michael Elizabeth Chastain
2003-12-03  5:05 Michael Elizabeth Chastain
2003-12-12 19:49 Michael Elizabeth Chastain
2003-12-13 10:18 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031124165047.GA2227@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox