From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1913 invoked by alias); 15 Jan 2004 14:23:52 -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 1723 invoked from network); 15 Jan 2004 14:23:50 -0000 Received: from unknown (HELO smtp10.atl.mindspring.net) (207.69.200.246) by sources.redhat.com with SMTP; 15 Jan 2004 14:23:50 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 1Ah8P0-0002el-00; Thu, 15 Jan 2004 09:23:18 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id D20B24B104; Thu, 15 Jan 2004 09:23:08 -0500 (EST) To: drow@mvista.com, gdb-patches@sources.redhat.com Subject: Re: RFA: Don't use obsavestring in dwarf2read Message-Id: <20040115142308.D20B24B104@berman.michael-chastain.com> Date: Thu, 15 Jan 2004 14:23:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-01/txt/msg00387.txt.bz2 I proofread this. I didn't think it worthwhile to run the test suite, because almost all tests are simple "load file / run / exit" that would not catch memory lifetime bugs. I have one concern. read_string and read_indirect_string return NULL to indicate a zero-length string. obstack_savestring understands this and copies an empty string "" into the obstack. In most of your changes, the string pointer is protected against being NULL, but in other changes, it is possible for the string pointer to be NULL. If the string is NULL, then your code will produce slightly different results than previously, which is a bit scary in the symtab reader. So could you do this in two places: SET_FIELD_PHYSNAME (*fp, physname ? physname : ""); fnp->physname = physname ? physname : ""; Other than that, it looks okay to me. I stared at it for a while to check that everything is coming from psymbol_obstack and symbol_obstack, not dwarf2_tmp_obstack or alloca'd memory. Michael C