From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10709 invoked by alias); 14 Feb 2002 16:44:45 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10626 invoked from network); 14 Feb 2002 16:44:43 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.7) by sources.redhat.com with SMTP; 14 Feb 2002 16:44:43 -0000 Received: from laocoon (laocoon.u-strasbg.fr [130.79.112.72]) by cerbere.u-strasbg.fr (8.9.3/8.8.7) with ESMTP id RAA26907 for ; Thu, 14 Feb 2002 17:44:42 +0100 Message-Id: <4.2.0.58.20020214173516.01d42828@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 14 Feb 2002 08:44:00 -0000 To: gdb-patches@sources.redhat.com From: Pierre Muller Subject: Re: [RFA] win32-nat printf and sprintf removal In-Reply-To: <20020214161350.GM23253@redhat.com> References: <3C6BD855.8030003@cygnus.com> <4.2.0.58.20020208182442.00ad05e0@ics.u-strasbg.fr> <4.2.0.58.20020208182442.00ad05e0@ics.u-strasbg.fr> <4.2.0.58.20020214121240.01a80208@ics.u-strasbg.fr> <3C6BD855.8030003@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-SW-Source: 2002-02/txt/msg00413.txt.bz2 At 17:13 14/02/2002 , Christopher Faylor a écrit: >On Thu, Feb 14, 2002 at 10:31:33AM -0500, Andrew Cagney wrote: > >Suggest adding a comment just above each sprintf() call indicating that > >buf is static (at least that way the next person won't be puzzled by > >this). > >There are three sprintfs in win32-nat.c. One uses a static buffer of 80 >bytes (which is overkill). The 'static char buf[80]' is two or three >lines above the use of sprintf. The other use of sprintf uses an >alloca'ed buffer. The alloca is directly above the sprintf. > >I don't think it makes sense to mention "this buffer is static" one line >below the definition of the buffer or "this buffer is allocated from the >stack" directly after the buffer is allocated on the stack. > >The moral of the story here is not that more comments are needed (at >least not in this case). The true moral is that you should be sensitive >to warnings in the code, you should be *very* sensitive to an increase >in warnings (in this case from zero to three) and you should test >changes thoroughly before submitting an "obvious" fix. You are completely right, I need to be more cautious, especially as my C knowledge still is quite lacunar. (I didn't know about the automatic disposal for alloca until today :() >It's possible, I guess, that the change of printf to printif_unfiltered >was an obvious fix. The change from sprintf to xasprintf was not. You >just have to do a 'grep -w sprintf' on the gdb sources to see that >sprintf is used quite frequently, so any change to xasprintf would have >to be justified. But there are also quite a lot of printf still lying around in gdb sources. I simply now believe that indeed changing printf into printf_unfiltered and even changing fprintf (stderr, ...) into fprintf_unfiltered (gdb_stderr,...) are much more "obvious" than the sprintf to xasprintf one. Moreover only the two former changes make improovements for GUI or other porgrams using GDB internally. Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99