[commit] Deprecate remaining STREQ uses

Daniel Jacobowitz drow@mvista.com
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 
> regularly).

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

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

Sure it isn't new.  Other people grumbling at you when you deprecate
things doesn't appear to be new either.

Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

More information about the Gdb-patches mailing list