From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70006 invoked by alias); 14 May 2017 03:19:09 -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 69971 invoked by uid 89); 14 May 2017 03:19:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=modest, 2017-05-08, HTo:U*eliz, HX-PHP-Originating-Script:rcube.php X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 14 May 2017 03:19:05 +0000 Received: by simark.ca (Postfix, from userid 33) id A23A21E4A2; Sat, 13 May 2017 23:19:06 -0400 (EDT) To: Eli Zaretskii Subject: Re: GDB 7.99.91 MinGW compilation error in cli-script.c X-PHP-Originating-Script: 33:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 14 May 2017 03:19:00 -0000 From: Simon Marchi Cc: gdb-patches@sourceware.org In-Reply-To: <83o9v3cs25.fsf@gnu.org> References: <20170504194442.63AAF60B72@joel.gnat.com> <83o9v3cs25.fsf@gnu.org> Message-ID: <91d9fc6cc7c07674a0b5cd02e7b1502b@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.5 X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00316.txt.bz2 On 2017-05-08 11:00, Eli Zaretskii wrote: > The reason is that std::to_string is guarded by the symbol > _GLIBCXX_HAVE_BROKEN_VSWPRINTF, which mingw.org's MinGW defines in its > os_defines.h, because msvcrt.dll's implementation of vswprintf is > incompatible with what C++11 expects. So GDB assumes here without > testing that this method is available, which is not true at least on > one platform. > > How best to solve this? I worked around by providing my own > implementation based on std::ostringstream, but I'm not sure this is > TRT. An alternative would be to use some less problematic API, since > currently cli-script.c is the only user of this method, and its needs > are quite modest. And if we do provide a replacement for to_string, > should the configure script probe for it, or should we condition it > specifically on MinGW and _GLIBCXX_HAVE_BROKEN_VSWPRINTF? > > Thoughts? I think the best solution would be a check at configure time. I think it's a function that can be quite handy, so it would be unfortunate if we had to avoid using it, especially if it's easy to implement ourselves for MinGW. A configure check would be more robust than checking for MinGW or _GLIBCXX_HAVE_BROKEN_VSWPRINTF specifically, in case another platform needs the replacement too, or if the define changes at some point. Note that you'll need to check for the specific overload of the function that we use, the one that accepts a parameter of std::vector::size_type (what .size() returns). In practice, I think we can consider that it will always correspond to size_t. Thanks, Simon