From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id 857DC3851C24 for ; Tue, 2 Jun 2020 13:24:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 857DC3851C24 Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-152-fT7Sh09xPaiu5W8ijIYbVQ-1; Tue, 02 Jun 2020 09:24:45 -0400 X-MC-Unique: fT7Sh09xPaiu5W8ijIYbVQ-1 Received: by mail-wr1-f70.google.com with SMTP id h92so1381347wrh.23 for ; Tue, 02 Jun 2020 06:24:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vnkh67EsVmCP4FCPDl1mJiEWn/zC05s8kt6eNRSyL0E=; b=oJo7xbXiudk2Lhk0lY210X+rl3IlglhyTe05JI2duB4uBfk5SoZAFyWRt7wBPohohN 1ydkusQG4OVKMQ/hWjN4ptOHPmWevqNVp21iyHYXaJEg/GbZ6fThlK0ZyjkxN3zOTsBE oIZn1JH9JJBREPfl7AuJLQCUH2Xbts/zdl2rEd1vxxp7G/rPeMLg89FhSFW0MNfGpUEL yeMDqnlKv127zb6Is/xYLgMJXA2aYs+UjTr9EhMjD7TuNMyHUvnJYGPL+N+STbNcnbIg MVZRp8nLFoXg4y0SlS3DNISzq1/pWi0Pnd70FQM4uTRIq4FG4NhaQU3fNeAm6zoHIvt+ bf3A== X-Gm-Message-State: AOAM530CFbB22LlOVSi1BN2ufXxHywH8Hso7qIGReF9ruYnBNKKVC4ce 1EmAjcib895BQaB41H3T+pRzPlTtGipKRQvyqjXKWIHa16Ap+uTx1aQfdpuc9gHpWK0XExrFi5A PN6yAC+8XHpC2lLemvheosg== X-Received: by 2002:a1c:2183:: with SMTP id h125mr3908814wmh.112.1591104283750; Tue, 02 Jun 2020 06:24:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyA1SSrvJpc2AogcPRR2gfu6rW/38I41RcP1qUoqzGkFLmNJirTDXOsVWLlL0+w8VXwP4IVaw== X-Received: by 2002:a1c:2183:: with SMTP id h125mr3908802wmh.112.1591104283517; Tue, 02 Jun 2020 06:24:43 -0700 (PDT) Received: from ?IPv6:2001:8a0:f922:c400:56ee:75ff:fe8d:232b? ([2001:8a0:f922:c400:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id l17sm4181114wrq.17.2020.06.02.06.24.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 06:24:42 -0700 (PDT) Subject: Re: [PATCH 2/3][gdb/testsuite] Fix global array leaks To: Tom de Vries , Tom Tromey References: <20200519162942.GA9014@delia> <87pnav3ezw.fsf@tromey.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <6c56aebe-c54a-5b86-a13a-d0432e544c5c@redhat.com> Date: Tue, 2 Jun 2020 14:24:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 13:24:49 -0000 On 6/2/20 2:07 PM, Tom de Vries wrote: > On 22-05-2020 22:13, Tom Tromey wrote: >>>>>>> "Tom" == Tom de Vries writes: >> >> Tom> Several test-cases define global arrays, which remain set after the test-case >> Tom> has run. This has the potential to cause tcl errors. >> >> Tom> Fix this by wrapping each test-case in a namespace. Add a README entry on how >> Tom> to do that. >> >> Tom> Tested on x86_64-linux. >> >> Tom> Any comments? >> >> This seems fine to me, but doesn't all the code in the namespace{} need >> to be reindented? > > I'm not sure. > > I based the style on what I saw Pedro doing here ( > https://sourceware.org/git/?p=binutils-gdb.git;a=blobdiff;f=gdb/testsuite/gdb.multi/multi-kill.exp;h=03bf8449cf87694c0153e2bbb2ff476cccb1e342;hp=ce6075045fc4a9e99987067bc22e4a86e089f9d5;hb=272c36b87f81fd64e5f4669730da72c39d0716b3;hpb=013707794a67269dd34fd8ae6e354e982c547dc0 > ). > I was going by: - we don't indent within-namespace code in C++. And I think that's a good thing, since if we assume the end goal of everything being inside a namespace, then the indentation is just a waste of horizontal space. TCL's usual practice may be different, I don't know. - reindenting everything in preexisting files seems like a lot of churn for little gain. Thanks, Pedro Alves