From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ZMbINLBPu2ceMDsAWB0awg (envelope-from ) for ; Sun, 23 Feb 2025 11:41:20 -0500 Received: by simark.ca (Postfix, from userid 112) id BEA171E05C; Sun, 23 Feb 2025 11:41:20 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.0 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 8EC7D1E05C for ; Sun, 23 Feb 2025 11:41:19 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3921E3858D37 for ; Sun, 23 Feb 2025 16:41:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3921E3858D37 Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by sourceware.org (Postfix) with ESMTP id 9055F3858D1E for ; Sun, 23 Feb 2025 16:40:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9055F3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9055F3858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:4190:8020::34 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1740328846; cv=none; b=exargOYPcvFx/XJIg2RV4CAXSM0vukTa3bB1g03eXJSxlGUmBtzdEbdjl6F/VhWEZhLMmBaHpb3tpbV+uFCr9DjBhDbCFVZWgGRo1Jze64gOiKlO0u4DpxiZVuCX6u49raInNpZLCcrZK9sJjdWdalgwE3AV6Mt7vfybNEwpkxE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1740328846; c=relaxed/simple; bh=xYGBqDOTUbNppHKe0jFraeBFxpTNaM7Tl4yHL3Y/wfU=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=g/WyrSgN4jz6FPnwGLTY2i8qWqxfhqj1Iywhmt8/uinZmtlKUao/A4WfesqAbeF1NU+1D5aNEJnkRZsMuWklfrwyrzhGkeqwYbU4EvZIxlE8u6bP1Mz+ow9NMd4+lhJLi32elMGT4+ikUYJbsVJPiZT4yf5fJwZ46+icWEai4lg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9055F3858D1E Received: by angie.orcam.me.uk (Postfix, from userid 500) id F143A92009C; Sun, 23 Feb 2025 17:40:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id E2DA692009B; Sun, 23 Feb 2025 16:40:45 +0000 (GMT) Date: Sun, 23 Feb 2025 16:40:45 +0000 (GMT) From: "Maciej W. Rozycki" To: Kevin Buettner , Milica Matic cc: gdb-patches@sourceware.org Subject: Re: [PATCH v12 1/2] Apply coding guidelines In-Reply-To: <20250219162124.62880782@f41-zbm-amd> Message-ID: References: <20250219130125.356900-1-milica.matic@htecgroup.com> <20250219130125.356900-3-milica.matic@htecgroup.com> <20250219162124.62880782@f41-zbm-amd> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On Wed, 19 Feb 2025, Kevin Buettner wrote: > > Format mips-tdep.c code as described on links: > > https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards > > https://www.gnu.org/prep/standards/standards.html#Comments > > --- > > gdb/mips-tdep.c | 395 +++++++++++++++++++++++++++--------------------- > > 1 file changed, 221 insertions(+), 174 deletions(-) > > This is okay. Kevin, thank you for your review. However I wasn't happy with some aspects of the proposal, so I have split it into pieces by the category, making individual commits self-contained, easy to navigate and consequently obvious to the reader. I'll appreciate if any future changes of this kind made to the MIPS backend follow this pattern. Strictly speaking I reckon our new-line rule for block comments preceding variable definitions only applies to ones outside functions, but I don't care either way, so I have retained these changes. I also made a couple of small adjustments which were missed around the places poked at. Unlike adding or removing new lines there is ongoing cost to code changes made as it affects `git blame' output. Therefore I have applied changes to places with actual style issues, but I decided against making block statements out of comments along with the single statements that follow them each in conditional blocks. I think the benefit outweighs the ongoing cost of their appearance in `git blame' output that requires an extra step to bypass this noise. I have no objection to using this style of course with new code or code that has to be otherwise changed anyway. Last but not least I can see no reason to merge adjacent comments into single block comments. There is no such requirement and there was often a reason to do it this way, such as to emphasize separation. So I have not applied this part either. I have adjusted commit headings and descriptions accordingly and posted the changes applied for easier reference. Milica, thank you for your contribution. Maciej