From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12185 invoked by alias); 14 May 2012 16:16:05 -0000 Received: (qmail 12166 invoked by uid 22791); 14 May 2012 16:16:02 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from elasmtp-mealy.atl.sa.earthlink.net (HELO elasmtp-mealy.atl.sa.earthlink.net) (209.86.89.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 May 2012 16:15:50 +0000 Received: from [68.96.200.16] (helo=macbook2.local) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1STxw5-0007lU-C4 for gdb@sourceware.org; Mon, 14 May 2012 12:15:49 -0400 Message-ID: <4FB12FB4.1070407@earthlink.net> Date: Mon, 14 May 2012 16:16:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: [mingw]gdb CVS HEAD build error References: <4FB05F17.7090701@gmail.com> <83k40fwk5k.fsf@gnu.org> <20120514045808.GT29339@adacore.com> <83ipfywyga.fsf@gnu.org> In-Reply-To: <83ipfywyga.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da94000cffccc987123ba1c4fdf8d99283c37350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00056.txt.bz2 On 5/14/12 8:53 AM, Eli Zaretskii wrote: >> Date: Sun, 13 May 2012 21:58:08 -0700 >> From: Joel Brobecker >> Cc: asmwarrior, gdb@sourceware.org >> >> Another possible option is to switch to gnulib's printf. I don't know >> if gnulib's configury would detect faulty or incomplete versions of >> printf like here > This is not an incomplete implementation, it's just that we are using > an unportable format specifier. We should be using what inttypes.h > says (or use LONGEST and plongest). > Yeah, I'll take care of this, I habitually forget about mingw not liking those directives. Stan