This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [commit] Deprecate remaining STREQ uses
- From: "Eli Zaretskii" <eliz at elta dot co dot il>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: kevinb at redhat dot com, drow at mvista dot com, gdb-patches at sources dot redhat dot com
- Date: Mon, 01 Dec 2003 21:07:32 +0200
- Subject: Re: [commit] Deprecate remaining STREQ uses
- References: <3FC119EB.1060102@gnu.org> <ufzgee29u.fsf@elta.co.il> <3FC234C0.1000500@gnu.org> <20031124165047.GA2227@nevyn.them.org> <1031124182547.ZM9776@localhost.localdomain> <3FC26407.9000704@gnu.org> <1031125000932.ZM11256@localhost.localdomain> <3FC60A75.8090803@gnu.org> <9178-Thu27Nov2003192422+0200-eliz@elta.co.il> <3FCB6275.2070403@gnu.org>
- Reply-to: Eli Zaretskii <eliz at elta dot co dot il>
> Date: Mon, 01 Dec 2003 10:47:01 -0500
> From: Andrew Cagney <cagney@gnu.org>
> >
> > But that's precisely why we have the patch review and approval
> > procedure, right? Maintainers who approve patches are supposed to
> > prevent code that uses deprecated machinery from being added.
>
> Very true. Explicit deprecation is a tool for making that part of the
> maintainer and contributor task far easier. Instead of wasting time
> trying to track and find all the things being eliminated, the
> contributor and reviewer can simply keep an eye out for deprecated in
> their patches
I'm not convinced that detecting STREQ is harder than detecting
DEPRECATED_STREQ.