From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79274 invoked by alias); 19 May 2017 13:39:35 -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 78904 invoked by uid 89); 19 May 2017 13:39:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=surely X-HELO: mail-wr0-f181.google.com Received: from mail-wr0-f181.google.com (HELO mail-wr0-f181.google.com) (209.85.128.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 May 2017 13:39:33 +0000 Received: by mail-wr0-f181.google.com with SMTP id l9so17597411wre.1 for ; Fri, 19 May 2017 06:39:36 -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-transfer-encoding; bh=BgzQA96BeR64n6n8GPOPgQEywCAV03SIypGknKPaKyY=; b=Z5UQCT7+EvFSgPSgeWFGe8116bTYQeEmOvXyo5Z6Y7GkpCmSxiJhOoFhlGt5b4SSwk tXu5UkD2B7WN31necW/VF/R+Bd9IjDUG7HVhuRxEA+PwUQzHAfxT+MGuAnundaL2hIEL 9l8HS4O/gLdqIS3J1U/BYH15ErBuS8+oPx61IlOnArUBiswa6RWhsAYoKo9j3HXaPxM2 BfNk4bRar90u2fq2R3rS2TwfWoRfoYInkD3CGZQiEgry79LTxChjIuTnZYWU/qzU9mN9 9HPfIAGQQ1/hXUhSPH1i+JG6nt5Itr5J/kXb/S01j3b/QLs6H4etOeswdUvJuiWCHgRd fcvQ== X-Gm-Message-State: AODbwcAv6dsqBnDShtxhYKoXODGM6gjCp4X/SEMnupH77QqRuBlEoVuW WteKMYcjXg4qIfC1 X-Received: by 10.223.170.67 with SMTP id q3mr3784279wrd.19.1495201175185; Fri, 19 May 2017 06:39:35 -0700 (PDT) Received: from [192.168.0.102] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id 17sm26814645wmn.7.2017.05.19.06.39.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 May 2017 06:39:34 -0700 (PDT) Subject: Re: Fix tui compilation with Solaris libcurses (PR tui/21482) To: Eli Zaretskii , Rainer Orth References: <32521e83-00b5-e2a8-faff-03b5407cfc67@redhat.com> <83h90h2dbu.fsf@gnu.org> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Fri, 19 May 2017 13:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <83h90h2dbu.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00444.txt.bz2 On 05/19/2017 02:20 PM, Eli Zaretskii wrote: >> From: Rainer Orth >> Cc: gdb-patches@sourceware.org >> Date: Fri, 19 May 2017 14:50:06 +0200 >> >> I've checked in the cast part now. Here's the NOMACROS part for >> gdb_curses.h. Tested as before on sparcv9-sun-solaris2.10 (curses) and >> amd64-pc-solaris2.12 (ncurses). Ok too? > > I think this should be guarded by some OS-specific macro, so as not to > affect other platforms, where the original problem doesn't exist. The problem exists, we just hadn't tripped on it yet. Googling around we see people running into curses defining "move" as macro for instance, which conflicts with std::move. So I'd rather take the opposite approach. GDB must be able to compile with NOMACROS defined on some hosts, so defining it everywhere makes gdb behave the same everywhere and reduces the testing axis. A patch introducing a problem for Solaris or any host using the same curses will be quickly exposed on any host. > (I > see 6 instances of these macros being tested in my ncurses headers, > and I'm not on Solaris.) Who knows what new problems this could cause? I expect it'll fix more problems than create them. Defining macros without some sort of namespace prefix in C++ is a sure recipe for problems. NOMACROS was surely invented to avoid these problems. Thanks, Pedro Alves