[commit] Deprecate remaining STREQ uses
Mon Nov 24 20:54:00 GMT 2003
On Mon, Nov 24, 2003 at 02:36:47PM -0500, Andrew Cagney wrote:
> >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
At least one now :) There are a number of other solutions to this.
Have you considered making the ARI mail contributors for certain
(low-false-positive) categories? Like, for instance, this one. The
gcc-regression mailing list has several scripts to pull the ChangeLog
entries since the last run and mail victims. It's extremely effective.
> - 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.
This is where we disagree, I think.
Not that I'm arguing with either of the above. But I believe that the
problems (below) need to be considered also. With work to make the ARI
more used (as opposed to useful) I think you could save everyone a lot
> >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
> 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
> 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
> ('m sure there's a second thread but can't find it).
Sure it isn't new. Other people grumbling at you when you deprecate
things doesn't appear to be new either.
MontaVista Software Debian GNU/Linux Developer
More information about the Gdb-patches