From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17968 invoked by alias); 24 Nov 2003 16:41:41 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17959 invoked from network); 24 Nov 2003 16:41:39 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 24 Nov 2003 16:41:39 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 950E12B8F; Mon, 24 Nov 2003 11:41:36 -0500 (EST) Message-ID: <3FC234C0.1000500@gnu.org> Date: Mon, 24 Nov 2003 16:41:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [commit] Deprecate remaining STREQ uses References: <3FC119EB.1060102@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-11/txt/msg00519.txt.bz2 > Date: Sun, 23 Nov 2003 15:34:51 -0500 >> From: Andrew Cagney >> >> This patch deprecates remaining STREQ and STREQ uses. These are the >> ones that weren't covered by my testing GDB on a stabs system. It is >> worth noting that the bulk occure in language specific files - this >> suggests an area that needs improved testsuite coverage. > > > Sorry, I don't get the rationale for renaming STR* into > DEPRECATED_STR*. Are we going to throw away the code that used > STREQN/STREQ? If not, I don't see any good reasons to do this, as > renaming the macro doesn't get us any closer to the goal of replacing > them with a simple call to the appropriate str* function. > > Could you please explain why the renaming is a good idea? Note that I'm renaming the _remaining_ STR*s and not all references. I previously went through GDB's source code and replaced every occurance of STREQ* that is covered(1) by GDB's testsuite (or was in #ifdef 0 code). Since the before/after results were identical, I'm pretty sure those changes were ok. Unfortunatly that still leaves GDB containing a notable number of STREQ references: 49 ada-lang.c 8 xcoffread.c 7 coffread.c 7 mdebugread.c 6 dbxread.c 6 rs6000-nat.c 5 p-typeprint.c 4 language.c 4 mipsread.c 3 dwarfread.c 3 mcore-rom.c 2 dwarf2read.c 2 eval.c 2 exec.c 2 f-lang.c 2 hpread.c 2 source.c 1 environ.c 1 hppa-tdep.c 1 objfiles.c 1 p-valprint.c 1 sparc-tdep.c 1 stack.c 1 target.c While I could blindly transform those remaining references, such an operation would be untested and consequently runs the very real risk of introducing bugs (remember my test run didn't cover them). Consequently they've been deprecated. Per the weekend(2), they'll later be removed. enjoy, Andrew (1) Using gcov. (2) Check todays ARI (http://sources.redhat.com/gdb/current/ari) and you'll see a number of items have hit zero reference counts.