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


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

David summarized the rationale nicely.  Some additional data points are 
useful though:

- no one looks at the ARI
Looking at the last month of weekly web page summaries they range from:
    2734	/gdb/
    ....
     170	/gdb/current/
     ...
      32	/ml/bug-gdb/2000-12/msg00014.html
but contain not one mention of the ARI (even though I refer to it 
regularly).

- no one should need to look at the ARI
GDB's code base should internally document the status of each interface. 
    That way, when someone goes to hack on something its status is very 
clear.  Contributors can look at a slab of code and know immediatly that 
there is a problem.  Maintainers can review a patch and know where a 
deprecated interface is being used.

- it's more transparent
It's clearly far harder for me (and you) to let slip through patches 
that contain deprecated references.

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

This isn't exactly new:

ChangeLog-1998: (struct frame_saved_regs): Deprecate.
ChangeLog-1998: (EXTRA_FRAME_INFO): Deprecate.
ChangeLog-1998: (get_frame_saved_regs): Deprecate. Copy the saved regs 
into the
ChangeLog-1998: * symfile.c (allocate_symtab): Deprecate use of
ChangeLog-1999:         memory-write-packet-size''.  Deprecate ``set 
remotepacketsize''.
ChangeLog-1999:         print_transfer_performance. Deprecate.
ChangeLog-1999: deprecated gdb_file_init_astream().
ChangeLog-1999: * serial.h (DEPRECATED_SERIAL_FD): Define.
ChangeLog-1999: * serial.c (deprecated_serial_fd): New function.
ChangeLog-1999: * ui-out.c (struct ui_out): Remove deprecated fields.

With STREQ discussed:

ChangeLog-2000: * TODO: Mention ``extern'' and ``STREQ'' cleanups.
ChangeLog-2000: * defs.h (STREQ, STRCMP, STREQN): Document that these 
macros are
http://sources.redhat.com/ml/gdb-patches/2000-q1/msg00667.html
('m sure there's a second thread but can't find it).

only shame is that I didn't realse that GCOV could be used back then to 
test the change.

Andrew


  parent reply	other threads:[~2003-11-24 19:36 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
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 [this message]
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=3FC25DCF.7060508@gnu.org \
    --to=cagney@gnu.org \
    --cc=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