From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30659 invoked by alias); 26 May 2005 01:41:22 -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 30633 invoked by uid 22791); 26 May 2005 01:41:16 -0000 Received: from ausmtp02.au.ibm.com (HELO ausmtp02.au.ibm.com) (202.81.18.187) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 26 May 2005 01:41:16 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp02.au.ibm.com (8.12.10/8.12.10) with ESMTP id j4Q1an2F189866; Thu, 26 May 2005 11:36:49 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.250.237]) by sd0208e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4Q1hs9Q145054; Thu, 26 May 2005 11:43:54 +1000 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.12.11/8.13.3) with ESMTP id j4Q1f1ej032748; Thu, 26 May 2005 11:41:01 +1000 Received: from plinuxt18.cn.ibm.com (plinuxt18.cn.ibm.com [9.181.140.28]) by d23av04.au.ibm.com (8.12.11/8.12.11) with ESMTP id j4Q1evnM032651; Thu, 26 May 2005 11:40:59 +1000 Date: Thu, 26 May 2005 03:11:00 -0000 From: Wu Zhou To: Eli Zaretskii cc: gdb@sources.redhat.com, gdb-patches@sources.redhat.com, mark.kettenis@xs4all.nl Subject: Re: about the usage of sprintf in gdb, specifically in gdb/remote.c In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-05/txt/msg00547.txt.bz2 On Wed, 25 May 2005, Eli Zaretskii wrote: > That might be so today, but if some day someone changes either the > size of buf[] or the format string, things could become messy. > > I'd say, if we leave sprintf here, let's at least use sizeof(buf) in > the call to sprintf instead of a literal 8 in the format string. Yes, you are right. With this point in mind, I prefer to use xsnprint in this place too. > As for the other 2 examples, I'd use safer functions there. It's > unreasonable to request that Joe Random Hacker who happens to read the > code should perform the amount of analysis you demonstrated to > convince him/herself that the code is safe. Most programmers won't go > to such lengths. Yes, I bet that too. My intention in doing so is only to see whether there are any really overflow. It is purely out of curiosity. :-) BTW, what is your point on my analysis in section 3.1. I believe it might incur an overflow. But I need to design a scenario to verify that. Cheers - Wu Zhou