From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32286 invoked by alias); 29 Jun 2007 05:16:36 -0000 Received: (qmail 32276 invoked by uid 22791); 29 Jun 2007 05:16:34 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 29 Jun 2007 05:16:31 +0000 Received: from kahikatea.snap.net.nz (207.61.255.123.dynamic.snap.net.nz [123.255.61.207]) by viper.snap.net.nz (Postfix) with ESMTP id 0D37D3D950A; Fri, 29 Jun 2007 17:16:29 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 5B2E88FBF6; Fri, 29 Jun 2007 17:16:19 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18052.38305.461372.362123@kahikatea.snap.net.nz> Date: Fri, 29 Jun 2007 05:51:00 -0000 To: msnyder@sonic.net Cc: gdb-patches@sourceware.org Subject: Re: [resubmit] memory leak, mi-cmd-var In-Reply-To: <5313.12.7.175.2.1183091734.squirrel@webmail.sonic.net> References: <5313.12.7.175.2.1183091734.squirrel@webmail.sonic.net> X-Mailer: VM 7.19 under Emacs 22.1.50.9 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-06/txt/msg00523.txt.bz2 > I left the test for NULL in place, because I can't convince myself > that it is un-necessary. mi_cmd_var_set_format (char *command, char **argv, int argc) is called like main (char **argv, int argc). So if argc=2, which it must be at this point, then argv[1] can't be NULL can it? If it is, there must be something seriously wrong with the arguments of its caller, mi_cmd_execute (elements of struct mi_parse *parse), and other MI commands will surely fail too. > Therefore the conservative approach is to > leave it in. I've moved it to earlier so that if it's goint to error, > we won't do unnecessary work. The conservative approach would be to wait until after the release, or at least the branch/branchpoint. In Emacs we went through a similar process before the release. Dan Nicolaescu reviewed the error list and submitted errors that he thought might cause problems. Members of the mailing list would comment as to whether they thought a change was need or not. Patches were only submitted once it was agreed that there was a potential problem. At least that's my recollection - I didn't get involved. -- Nick http://www.inet.net.nz/~nickrob