From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by sourceware.org (Postfix) with ESMTPS id 3C1053858D33 for ; Thu, 6 Jul 2023 16:47:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3C1053858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-3fbea147034so9922675e9.0 for ; Thu, 06 Jul 2023 09:47:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688662025; x=1691254025; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lCriU2KxldjVZ+tUlMe0mT0MmMDejdi5a8AIlCuT+V8=; b=jWO0EcanWQJhQAp+s+5d6+CHPsjCnD78t7faBck6XJcFcITL5LznlFRE0pTIME9swZ twlheGsl1waaVzc4WUkVUN+612pxBJYDdURxAHZZ66zyzBzlhtZCJg343TBfTU/ljCau 2c69r7s4N9BC/nMs+ojgefybV2w6qKpRBrUIAHYGuabthcjyl2dJXQ6Eif7w3ST8tVn5 2aFq17RuReZmrUD9y6Kw0G/JYxyxMRman7ek/TR0IYvBV825U/hveqdY2KdMobepf9dJ f3jbYXg0K+rkHGh1j3gy3NmdkmAbZXUkwTCeVmXfd2dVzoeZWAw2DtbVoOTT3L+qY24h QfaA== X-Gm-Message-State: ABy/qLamJhDebr4B+wsy9/tv62BnLleMA84iQiL2+qNingM33tfKPTNc aEJS/vHvdgSZFfz9sqgXr3jThbzzXHA= X-Google-Smtp-Source: APBJJlEbP0y/e5PoAfSNWJoPVoT7x+YK4YP6Ba2ivQrMSVNBGMxjH97Tj8Ya+cKMcEw+L2IE7mLwjQ== X-Received: by 2002:a7b:cd12:0:b0:3fb:9474:54cd with SMTP id f18-20020a7bcd12000000b003fb947454cdmr896387wmj.19.1688662024633; Thu, 06 Jul 2023 09:47:04 -0700 (PDT) Received: from ?IPV6:2001:8a0:f91d:bc00:4994:a784:f998:13bf? ([2001:8a0:f91d:bc00:4994:a784:f998:13bf]) by smtp.gmail.com with ESMTPSA id l11-20020a1c790b000000b003fb416d732csm88162wme.6.2023.07.06.09.47.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Jul 2023 09:47:04 -0700 (PDT) Message-ID: Date: Thu, 6 Jul 2023 17:47:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH] Linux: Avoid pread64/pwrite64 for high memory addresses (PR gdb/30525) Content-Language: en-US To: Tom Tromey Cc: Andrew Burgess , gdb-patches@sourceware.org, Matt Turner References: <20230705134141.1441753-1-pedro@palves.net> <87a5wakzo4.fsf@redhat.com> <87ilaxukmw.fsf@tromey.com> From: Pedro Alves In-Reply-To: <87ilaxukmw.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023-07-06 16:25, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > > Pedro> I just realized that the lseek path, which I just reindented, has an if branch > Pedro> with more than one line which isn't using braces... The patch should at least be > Pedro> consistent in all the lines it touches... :-) If we follow the documented convention, > Pedro> then here's what we get. > > Pedro> WDYT? Should we tweak the convention instead? > > I tend to interpret this rule as "two statements and/or comments", so > braces are required if there's a comment but not for a single statement > that happens to be broken up across multiple lines. > I don't see how the current wording leaves any room for interpretation, but I could definitely see that the wording may have overreached the original intention. I remembered this rule being discussed on the list, (but not the discussion itself), so I did some digging, and found it. It all started here: https://inbox.sourceware.org/gdb-patches/20111218115931.GA22952@host2.jankratochvil.net/ and then a few weeks later another similar discussion happened, which led Jan proposing adding formalizing the convention: https://inbox.sourceware.org/gdb-patches/CADPb22Q9qi3TsYw3ZFkAyuO6a0VEJ_wtM_4pe_tXzDW5myi29Q@mail.gmail.com/ Curiously, Eli had pointed out the "comments or more ?" issue here: https://inbox.sourceware.org/gdb-patches/831ur4kot7.fsf@gnu.org/ but sadly there was no answer. >From what I can tell in those two threads, this was really only about the comments case. I'll drop the braces from my patch and merge it. As for the text in the wiki, how about something like below. (Note this tweaks the existing example to use "cond" instead of "i", since we don't do implicit bool conversions, and "i" looks like an int.) ``` Per the GNU coding standards, single statements are not wrapped in braces, while multiple statements are. Thus, if you need to wrap a statement, write: if (cond) func (foo (), bar ()); and not: if (cond) { func (foo (), bar ()); } As a GDB-specific rule, statements preceded by comments should also be wrapped in braces, as they look like separate statements: if (cond) { /* Return success. */ return 0; } and not: if (cond) /* Return success. */ return 0; ``` Oh the irony: https://inbox.sourceware.org/gdb-patches/4F1011EA.1030509@redhat.com/ :-)