From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31193 invoked by alias); 29 Jan 2014 05:45:59 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 31181 invoked by uid 89); 29 Jan 2014 05:45:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ie0-f172.google.com Received: from mail-ie0-f172.google.com (HELO mail-ie0-f172.google.com) (209.85.223.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 29 Jan 2014 05:45:57 +0000 Received: by mail-ie0-f172.google.com with SMTP id e14so1698735iej.17 for ; Tue, 28 Jan 2014 21:45:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0zTJ1pBjmB4vZLtvczXaJ+uz1eHAn/FqEl2G0uSW//4=; b=POv/1aEc+nY62w7OpdFoaXyzEmWjIqeIKEx/EYFLhNOwsXj7OcMHBMlV+cGpXMsj2d FEZpXnij97Zbg2oVzUQw9J0i9Ivy0uOFPmgVXRxdKzErw0/gX8wh5D1sZkREOPId6Scp 2lyrqwYjegG8EXtAlH5yEFkYVVy/JtR6r+5h38q99mVC13APtfelwtRdbrD3GD8FH7Y5 9EMD8HQcc4C0miVSuDvtmnloyAFAMVIwejlVLINU25RdaGPezHpD9t7Oy9caZLBPTILL b86GUs6uQ5P6dir2URTlNh8anI8tJ2lfZvj719/rkitkeQj1wN7mV+/TpwzfSHqU7Ao1 rS9A== X-Gm-Message-State: ALoCoQnuuFSN9PfRNulJjJkiRdLAIqPQJ0AwDA5IAaLzYcEQcN9O/ZuH9Vk+3RpXpUsemEPXGBjxHt80qcYAdA/d93tl18k7uQvTx5lO34Sgvrl9g3GgD9mGwk97mzrcl4BqBxnoZchBYngX1ZeCKWK3Nq9HLTlK/OJ+intfeS5qUk9qlpcd2gyjsDcuhCd4sUikcV/ONVi3FdqDKbfUdAOZWoilVpsGmw== MIME-Version: 1.0 X-Received: by 10.42.62.143 with SMTP id y15mr645341ich.14.1390974355402; Tue, 28 Jan 2014 21:45:55 -0800 (PST) Received: by 10.64.58.77 with HTTP; Tue, 28 Jan 2014 21:45:55 -0800 (PST) In-Reply-To: <52E3ADB8.60707@codesourcery.com> References: <52E3ADB8.60707@codesourcery.com> Date: Wed, 29 Jan 2014 05:45:00 -0000 Message-ID: Subject: Re: [PATCH 1/3] change gdbserver to use hashtab: list->table From: Doug Evans To: Yao Qi Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg01028.txt.bz2 On Sat, Jan 25, 2014 at 4:27 AM, Yao Qi wrote: >> 2014-01-24 Doug Evans >> >> * inferiors.h (struct inferior_table): Renamed from struct >> inferior_list. All uses updated. >> (struct inferior_table_entry): Renamed from struct >> inferior_list_entry. All uses updated. >> (add_inferior_to_table): Renamed from add_inferior_to_list. >> * inferiors.c (*): Update. > > Do we need entries like this? Since "All uses updated" is written > above, probably we don't need these entries. In gnu coding standards: > > "When you change the calling sequence of a function in a simple > fashion, and you change all the callers of the function to use the new > calling sequence, there is no need to make individual entries for all > the callers that you changed. Just write in the entry for the function > being called, =E2=80=9CAll callers changed=E2=80=9D" That's a very good question, and the answer is "We haven't agreed on how to apply that rule from the gnu coding standards." Some go for listing everything function that is not in the same file that the originating change was in. Some go for applying the rule throughout (which is what you're advocating), regardless of which files are touched. I prefer the latter, but until we have a clear agreement on how to write these kinds of entries, I sometimes punt and just go with the flow. And that is why I wrote it that way.