From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BbiJ3-0005sk-0H for qemu-devel@nongnu.org; Sat, 19 Jun 2004 12:03:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BbiJ1-0005s8-N2 for qemu-devel@nongnu.org; Sat, 19 Jun 2004 12:03:00 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BbiJ1-0005s1-JV for qemu-devel@nongnu.org; Sat, 19 Jun 2004 12:02:59 -0400 Received: from [206.72.67.39] (helo=claudius.sentinelchicken.org) by monty-python.gnu.org with smtp (Exim 4.34) id 1BbiHf-0004If-LI for qemu-devel@nongnu.org; Sat, 19 Jun 2004 12:01:36 -0400 Date: Sat, 19 Jun 2004 09:01:34 -0700 From: Tim Subject: Re: [Qemu-devel] [PATCH] security_20040618 Message-ID: <20040619160134.GD1962@sentinelchicken.org> References: <20040618184036.GA1874@sentinelchicken.org> <40D45F74.9010701@bellard.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D45F74.9010701@bellard.org> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > Thank you for the fixes. np. > For malloc() returning NULL, if your patch just says "malloc error", I > don't consider it is a good fix. Yeah, I figured it would be very context specific for these. In low-level functions, you'd just want to return an error value (that would need to be checked as well) and at higher-level stuff, perhaps you'd just bail out, and clean up before killing the process. For now, I will leave my patch as it stands in this respect. It doesn't implement a single NULL check for {m,re}alloc, it merely adds TODO comments. Later on, after I address some other things, perhaps I will come back and attack these with a different patch. > I see that you added many snprintf(). I don't like that because > pstrcpy() does exactly the right thing and it is faster and simpler. There were some cases where I switched sprintf() with snprintf(). For those, I figure they should stay that way. For the strcpy() -> snprintf() changes, yes, I agree that your pstrcpy() is faster. I'll review those and change them where I can. However, pstrcpy() may not be available via includes to every file, so I'll probably let the snprintf() stand if I run into that problem. Were you able to look at my proposed changes to pstrcpy()? What do you think of them? Thanks for the feedback! tim