From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19934 invoked by alias); 17 Jan 2006 20:11:17 -0000 Received: (qmail 19925 invoked by uid 22791); 17 Jan 2006 20:11:16 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 17 Jan 2006 20:11:15 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-4-200.inter.net.il [80.230.4.200]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id DJT82833 (AUTH halo1); Tue, 17 Jan 2006 22:11:10 +0200 (IST) Date: Tue, 17 Jan 2006 20:11:00 -0000 Message-Id: From: Eli Zaretskii To: gdb-patches@sourceware.org In-reply-to: <20060117194624.GA10188@nevyn.them.org> (message from Daniel Jacobowitz on Tue, 17 Jan 2006 14:46:24 -0500) Subject: Re: [ob] More warnings; Call for assistance Reply-to: Eli Zaretskii References: <20060117151730.GA2420@nevyn.them.org> <20060117152156.GA3115@nevyn.them.org> <8f2776cb0601171137yffbcd4exefdefe7c8a79bbf3@mail.gmail.com> <20060117194624.GA10188@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00222.txt.bz2 > Date: Tue, 17 Jan 2006 14:46:24 -0500 > From: Daniel Jacobowitz > > I disagree, because (IIRC) Debian users have filed at least two bugs > where failures in this code have led to user input crashing GDB: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186037 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=231162 These aren't crashes, GDB prints a legible error message and returns to top level. However, internal_error is not the best idea for these situations, so we probably should arrange for GDB to mutter something about possibly bad format instead, and not to ask whether to dump core. > The advantages of static format checking, in the face of that, are > pretty large. No matter what you do, as long as users are typing format strings, it will always be possible for a format to exceed our wildest imagination. You cannot beat that, unless you are willing to artificially restrict users to some safe and/or easily parsable subset of valid formats, which I think we shouldn't do. > avoid the use of standard printf Avoid? how? are you saying that we should write our own version of printf?