From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23431 invoked by alias); 3 Nov 2002 00:25:13 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 23388 invoked from network); 3 Nov 2002 00:25:12 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.163.212.31) by sources.redhat.com with SMTP; 3 Nov 2002 00:25:12 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id B254D357E; Sat, 2 Nov 2002 16:25:11 -0800 (PST) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id gA30P9D11901; Sat, 2 Nov 2002 16:25:09 -0800 Date: Sat, 02 Nov 2002 16:25:00 -0000 Message-Id: <200211030025.gA30P9D11901@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Isamu Hasegawa Cc: "Jakub Jelinek Glibc hackers" Subject: Re: Regex memory management In-Reply-To: Jakub Jelinek's message of Wednesday, 30 October 2002 15:59:31 +0100 <20021030155931.W3451@sunsite.ms.mff.cuni.cz> Emacs: ballast for RAM. X-SW-Source: 2002-11/txt/msg00002.txt.bz2 We really should have the regex code audited for possible memory leaks in error conditions, since Jakub has already observed some. If Isamu doesn't have time, perhaps someone else can find time to do it soon. Jakub's obstack suggestions sound good to me, and converting to that makes it vastly easier to be sure the code is correct. But I don't know the regex code and its allocation properties at all, so as to say that the obstack model fits acceptably right in all cases.