From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47456 invoked by alias); 26 May 2017 10:54:05 -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 47433 invoked by uid 89); 26 May 2017 10:54:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=bearing, concise X-HELO: mail-wm0-f44.google.com Received: from mail-wm0-f44.google.com (HELO mail-wm0-f44.google.com) (74.125.82.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 26 May 2017 10:54:04 +0000 Received: by mail-wm0-f44.google.com with SMTP id 7so124459290wmo.1 for ; Fri, 26 May 2017 03:54:07 -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=nY+nQpfdKloWCpCFGU19clLzDNXezrzKjvEErknZCi4=; b=ZsJhV792pTh+YPdv493V3nNBx3kZMTHm9k91NOcfEcVPlGFQLSSyF6l84wvqdnf5Q7 YLXlLwfzeWVqpCUXKq106TsO7A+Lbn25amm0dIPhFmO+Jy5t/cdn/ZEH/814GjlKxjqo ajLl+/F8UftL9xJAG3RKywVJEF8+4i+je4CGLyPMDxYQ0xpsTZPpFpLZPu1xCPHrkrUB owIE5NcDrvJ69zmRP+kVXx2c06kB0SGSmonFHhDSepKTLnZsdQWfgPYQb/GTXV4E2qol 8qAdi0W5xL8+KXYVZ0wsPDeJLFzNaHWAUzCqh49hO7yauntZRjHbucp94VLmMc830aeY gC/g== X-Gm-Message-State: AODbwcC4f2nFpei/vtIPLJLUKICivtJ4vljTUamgezGjBu1cbBPdxn+7 8wU8Uu1gyRIGUU+68HHnAw== X-Received: by 10.223.179.92 with SMTP id k28mr1127825wrd.118.1495796045397; Fri, 26 May 2017 03:54:05 -0700 (PDT) Received: from [192.168.0.102] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id c8sm1405804wme.3.2017.05.26.03.54.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 May 2017 03:54:04 -0700 (PDT) Subject: Re: GDB 7.99.91 MinGW compilation error in cli-script.c To: Eli Zaretskii References: <83fug35v70.fsf@gnu.org> <83y3tt2ow0.fsf@gnu.org> <83vaox2j0w.fsf@gnu.org> <7017128a-7b51-5436-657b-58807d04eb02@redhat.com> <83vaouns1q.fsf@gnu.org> <837f18ohr2.fsf@gnu.org> <54594002-5d70-9ff8-c481-0cbfc8c68c7b@redhat.com> <834lwam7n4.fsf@gnu.org> <20170524193716.5arjibe4s5efvgj7@adacore.com> <15568468-0852-d786-8777-4adbd16825a0@redhat.com> <83tw48jc0f.fsf@gnu.org> Cc: brobecker@adacore.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <209349d7-a2b5-74ab-3b49-553d6e9ed97e@redhat.com> Date: Fri, 26 May 2017 10:54: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: <83tw48jc0f.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00557.txt.bz2 On 05/26/2017 08:46 AM, Eli Zaretskii wrote: >> Cc: simon.marchi@polymtl.ca, gdb-patches@sourceware.org >> From: Pedro Alves >> Date: Thu, 25 May 2017 11:12:22 +0100 >> >> This: >> >>>> + (std::to_string) [REPLACE_TO_STRING]: Provide a replacement >>>> + implementation. >> >> Should really be: >> >> (gdb::to_string): Define. > > The code says std::to_string, though. So it sounds like some coding > conventions are being applied here of which I wasn't aware, and > neither is Emacs. Are these conventions described somewhere? Just the standard GNU conventions. The code is defining a new function template called gdb::to_string. Simplified: namespace gdb { template std::string to_string (const T &val); } There are two implementations of that, one for mingw, written as a new function template in place. And another which is importing std::to_string into the gdb namespace. But whatever the implementations, it's implementation detail of gdb::to_string. So gdb::to_string is meant as a std::to_string replacement, yes. But that's not "what", that's "why". This is really the same as if the patch looked like this: + namespace gdb { + std::string tostr(int i) + { + #ifdef MINGW + // something using sprintf; + #else + return std::to_string (i); + #endif + } + } The ChangeLog entry would be something like: (gdb::tostr): Define. too, not: (std::to_string): Provide a replacement. And the entry is not conditional on MINGW, since we're adding both #ifdef and #ifndef implementations at the same time. > >> and you need an entry for the cli/cli-script.c change, like: >> >> * cli/cli-script.c (user_args::insert_args): Use it. > > I added that, Thank you. > but once again, the convention to put the > fully-qualified symbol name in the log entry should be documented, if > it isn't already, because Emacs doesn't do that, at least not by > default. I can't see how what Emacs does has any bearing here, since AFAIK, Emacs isn't written in C++. Here there's no namespace at all, and "insert_args" is a method of the user_args class. So I find the above a natural a concise way to write the symbol's name. > Is this convention applied consistently across the project? Sure, grep ChangeLog for "::". Thanks, Pedro Alves