From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24134 invoked by alias); 13 Oct 2016 15:27:45 -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 24035 invoked by uid 89); 13 Oct 2016 15:27:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=person X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Oct 2016 15:27:43 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E476AC05A28A; Thu, 13 Oct 2016 15:27:40 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9DFRbZv024613; Thu, 13 Oct 2016 11:27:38 -0400 Subject: Re: [RFA 09/22] Remove make_cleanup_restore_current_ui To: Eli Zaretskii References: <1474949330-4307-1-git-send-email-tom@tromey.com> <1474949330-4307-10-git-send-email-tom@tromey.com> <2f79a489b9090701f15fc04e0017c236@simark.ca> <87y41xd0dt.fsf@tromey.com> <1f5898b8-6be9-48e6-4312-72ec90e7810e@redhat.com> <87insxmbnd.fsf@tromey.com> <2855e2ec-46dc-71b7-9943-8edaebcbef90@redhat.com> <8337k0aicw.fsf@gnu.org> <6f27db2e-4b88-b72a-5836-080c3583eb7f@redhat.com> <83r37k8ifg.fsf@gnu.org> <83lgxs8fyj.fsf@gnu.org> Cc: tom@tromey.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <04d27c33-e99f-e5f0-a64c-57bd7bca8b42@redhat.com> Date: Thu, 13 Oct 2016 15:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <83lgxs8fyj.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00380.txt.bz2 I hadn't answered everything. Correcting that now. On 10/13/2016 03:46 PM, Eli Zaretskii wrote: >> You're automatically assuming it's a burden. I believe that's >> false. > > It should be clear and agreed by all that maintaining two > implementations for a single feature is more work than maintaining > just one. Sure, as general principle. In this particular case, I can't imagine any amount of significant work. >>>> Several others have said they think this is a good idea. I've even >>>> ran this idea through the libstdc++ maintainer in person at the Cauldron. >>>> Trevor said he wants to do this in gcc as well. >>> >>> I just wanted to voice my opposition, that's all. I don't have to >>> give up just because a few others think otherwise. Right? >> >> Of course. The problem is that your opinion is interpreted as >> a hard blocker. The result is stalling. > > If there are no more convincing arguments, then a usual way out of > stalling is to find some compromise. Is that possible in this case? I don't think so. >>>> If redirecting to C++11 std::unique_ptr turns out to cause trouble, or >>>> I'm hit by a bus, then it's trivial to remove that redirection. All it >>>> takes is remove a handful of lines of code guarded with >>>> #if __cplusplus >= 201103 to always go through the fallback implementation. >>> >>> Once again, it's not just this single patch that bothers me. Once we >>> have enough of these #if's, removing them is not necessarily a trivial >> >> And not "not necessarily" either... This just looks like fear of >> the unknown, I'm afraid. > > What exactly is unknown here? The amount of work it'd take to remove the #ifs. >>> matter, especially when most of the builds, perhaps even all of them, >>> have been using the C++11 code path all the time, and the other one >>> has simply bitrotted. >> >> As I've said before, we can make use of the buildbot for that. >> If the fallback code breaks, you get an immediate email notification. > > If someone sets it up to build both with and without C++11, yes. > A.k.a. "maintenance burden". All you need is one of buildbots testing gdb on an older distro that doesn't have a new enough compiler. It may even be already there -- e.g., mjw's debian build bot. So probably zero work, actually. Thanks, Pedro Alves