From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-28994-listarch-gdb-patches=sources.redhat.com@sources.redhat.com>
Received: (qmail 16474 invoked by alias); 1 Dec 2003 19:08:56 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 16464 invoked from network); 1 Dec 2003 19:08:56 -0000
Received: from unknown (HELO bilbo.inter.net.il) (192.114.186.18)
  by sources.redhat.com with SMTP; 1 Dec 2003 19:08:56 -0000
Received: from zaretski ([80.230.143.229])
	by bilbo.inter.net.il (Mirapoint Messaging Server MOS 3.3.8-GR)
	with ESMTP id BZL27587;
	Mon, 1 Dec 2003 21:08:13 +0200 (IST)
Date: Mon, 01 Dec 2003 19:08:00 -0000
From: "Eli Zaretskii" <eliz@elta.co.il>
To: Andrew Cagney <cagney@gnu.org>
Message-Id: <6654-Mon01Dec2003210731+0200-eliz@elta.co.il>
CC: kevinb@redhat.com, drow@mvista.com, gdb-patches@sources.redhat.com
In-reply-to: <3FCB6275.2070403@gnu.org> (message from Andrew Cagney on Mon, 01
	Dec 2003 10:47:01 -0500)
Subject: Re: [commit] Deprecate remaining STREQ uses
Reply-to: Eli Zaretskii <eliz@elta.co.il>
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>
X-SW-Source: 2003-12/txt/msg00023.txt.bz2

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