From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15064 invoked by alias); 16 Sep 2004 15:16:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 14986 invoked from network); 16 Sep 2004 15:16:25 -0000 Received: from unknown (HELO caip.rutgers.edu) (128.6.236.10) by sourceware.org with SMTP; 16 Sep 2004 15:16:25 -0000 Received: from caip.rutgers.edu (localhost [127.0.0.1]) by caip.rutgers.edu (8.12.11/8.12.9) with ESMTP id i8GFGPr8010785 for ; Thu, 16 Sep 2004 11:16:25 -0400 (EDT) Received: (from ghazi@localhost) by caip.rutgers.edu (8.12.11/8.12.9/Submit) id i8GFGOkV010784 for gcc@gcc.gnu.org; Thu, 16 Sep 2004 11:16:24 -0400 (EDT) Date: Thu, 16 Sep 2004 15:41:00 -0000 From: "Kaveh R. Ghazi" Message-Id: <200409161516.i8GFGOkV010784@caip.rutgers.edu> To: gcc@gcc.gnu.org Subject: Using alloca in function parameters buggy or works ??? X-SW-Source: 2004-09/txt/msg00988.txt.bz2 I'm looking over some memory leaks in gcc and I'm seeing lots of funny uses of concat like this from gcc.c:is_directory() strcmp (path, concat (dir_separator_str, "lib", dir_separator_str, ".", NULL)) It's pretty clear this memory allocation never gets free'd. I'd like to replace stuff like this with ACONCAT from libiberty which uses alloca and thus doesn't leak. Normally people don't like alloca I assume because if the backup libiberty C_alloca is used (which uses malloc underneath the hood), sometimes stuff isn't free'd because we don't call alloca(0) anywhere. Then memory use balloons in some edge cases. However we're already leaking here so if it was a "balloon" case we'd already know about it. :-) I'd like to make as little code change as possible for these cases, which means putting the ACONCAT use (and thus a call to alloca) right in there as a function call parameter. My question is that I seem to recall passing the result of alloca immediately as a function parameter was buggy at some point in GCC. Using such a version might trigger a bootstrap failure if that buggy GCC is used in stage1. So I'm wondering: 1. Was this bug in any released version of GCC that we care about? 2. Does my example above trigger the bug? 3. Any simple workaround? (Other than don't do that.) Thanks, --Kaveh -- Kaveh R. Ghazi ghazi@caip.rutgers.edu