From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29552 invoked by alias); 22 Apr 2003 21:15:39 -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 29537 invoked from network); 22 Apr 2003 21:15:39 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 22 Apr 2003 21:15:38 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 193E22B2F; Tue, 22 Apr 2003 17:15:31 -0400 (EDT) Message-ID: <3EA5B0F2.5000908@redhat.com> Date: Tue, 22 Apr 2003 21:15:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz , Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: PATCH: Add type_sprint() function to return type in string form References: <20030418152426.A93348@molenda.com> <20030422032629.GB5033@nevyn.them.org> <3EA57249.5020104@redhat.com> <20030422165455.GA31686@nevyn.them.org> <3EA57BD9.5020502@redhat.com> <20030422173348.GA325@nevyn.them.org> <3EA5961E.3060102@redhat.com> <20030422192827.GA21651@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00414.txt.bz2 >> You're kidding right? >> >> The ARI indicates that all sprintf calls should be replaced with either >> snprintf or xasprintf. >> >> Replacing sprintf with functions that are immune to buffer overrun >> problems, eliminates an entire class of bug. >> >> Even something as simple as: >> char buf[100000000]; >> sprintf (buf, _("a")); >> is broken. > > > No, I'm not kidding. I've worked in computer security for about six > years now and I still use sprintf. It's simple, it's effective, and if > you use it reasonably carefully, nothing will go wrong. That also applies to snprintf and xasprintf. > Not to mention that there are a number of buggy implementations of > snprintf; they're slowly starting to fade from use, thank the lord, but > you still see 'em now and again. If GDB encounters a system with a buggy snprintf implementation, it should use the one in libiberty. If libiberty's is buggy, some one should fix it. > Of course, in those six years I've had this argument about ten times. > It seems to be about a 50/50 split between developers. > And nothing involving translation is simple. There are tradeoffs. Things like the 80/20 rule (80% of bugs fixed with 20% of the effort); zero tolerance (complete elimination of risky coding pratices). This was seen with Kevin's recent elimination of of complain that flushed out numerous -Wformat problems. As for replacing the existing sprintf calls, like STREQ et.al., anyone wanting to do this will need to come up with a way of demonstrating that the translation was `probably' correct. One trick is to only convert lines that GCOV identifies as being executed. Andrew