From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18976 invoked by alias); 29 Apr 2005 22:54:43 -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 18936 invoked from network); 29 Apr 2005 22:54:38 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 29 Apr 2005 22:54:38 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j3TMsbv2024774 for ; Fri, 29 Apr 2005 18:54:37 -0400 Received: from zenia.home.redhat.com (sebastian-int.corp.redhat.com [172.16.52.221]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j3TMsaO19074; Fri, 29 Apr 2005 18:54:37 -0400 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: PATCH: allocate namecopy on heap, not stack References: <20050429213922.GA9371@nevyn.them.org> From: Jim Blandy Date: Fri, 29 Apr 2005 22:54:00 -0000 In-Reply-To: <20050429213922.GA9371@nevyn.them.org> Message-ID: User-Agent: Gnus/5.090 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-04/txt/msg00438.txt.bz2 Daniel Jacobowitz writes: > On Fri, Apr 29, 2005 at 04:35:35PM -0500, Jim Blandy wrote: > > > > Committed as obvious. > > > > 2005-04-28 Jim Blandy > > > > * parse.c (namecopy): Change allocation conventions. > > (namecopy_size): New variable. > > (copy_name): Allocate namecopy using xrealloc, instead of assuming > > it has adequate space allocated to it. > > (parse_exp_1): Don't try to allocate space for namecopy here. > > What prompted ths change? Even "obvious" patches deserve an > explanation. Certainly --- did you see this? + + /* A temporary buffer for identifiers, so we can null-terminate them. + + We allocate this with xrealloc. parse_exp_1 used to allocate with + alloca, using the size of the whole expression as a conservative + estimate of the space needed. However, macro expansion can + introduce names longer than the original expression; there's no + practical way to know beforehand how large that might be. */ + char *namecopy; + size_t namecopy_size;