From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-hacker-return-7138-listarch-libc-hacker=sources.redhat.com@sources.redhat.com>
Received: (qmail 21798 invoked by alias); 29 Dec 2003 21:10:36 -0000
Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:libc-hacker-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/libc-hacker/>
List-Post: <mailto:libc-hacker@sources.redhat.com>
List-Help: <mailto:libc-hacker-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: libc-hacker-owner@sources.redhat.com
Received: (qmail 21767 invoked from network); 29 Dec 2003 21:10:35 -0000
Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130)
  by sources.redhat.com with SMTP; 29 Dec 2003 21:10:35 -0000
Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228])
	by gateway.sf.frob.com (Postfix) with ESMTP
	id A8290357B; Mon, 29 Dec 2003 13:10:34 -0800 (PST)
Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1])
	by magilla.sf.frob.com (8.12.9/8.12.9) with ESMTP id hBTLAXHi012185;
	Mon, 29 Dec 2003 13:10:33 -0800
Received: (from roland@localhost)
	by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id hBTLAXW6012181;
	Mon, 29 Dec 2003 13:10:33 -0800
Date: Mon, 29 Dec 2003 21:10:00 -0000
Message-Id: <200312292110.hBTLAXW6012181@magilla.sf.frob.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Roland McGrath <roland@redhat.com>
To: Ulrich Drepper <drepper@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>,
	Glibc hackers <libc-hacker@sources.redhat.com>
Subject: Re: [PATCH] Small regexec.c fixes
In-Reply-To: Ulrich Drepper's message of  Monday, 29 December 2003 09:56:13 -0800 <3FF06ABD.6090300@redhat.com>
X-Shopping-List: 
   (1) Odious absorbers
   (2) Valiant confrontations
   (3) Virulent witch hands
X-SW-Source: 2003-12/txt/msg00099.txt.bz2

> I've applied the patch but in general we should avoid adding much code
> to free memory in case allocation fails.  Maybe to free some huge blocks
> but not more.  If the app runs out of memory it'll very soon terminate.
>  No need to bloat the code to help doing this.

I disagree completely.  It is important that library code never leak.  It
very well might be used in server situations where allocations can fail at
maximum load, or with unreasonable client input, but then enough more
memory gets freed by cleaning up resources associated with clients as they
die, that the server need never die.