From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30842 invoked by alias); 11 Sep 2004 19:43:30 -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 30834 invoked from network); 11 Sep 2004 19:43:29 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sourceware.org with SMTP; 11 Sep 2004 19:43:29 -0000 Received: from localhost (localhost [127.0.0.1]) by nile.gnat.com (Postfix) with ESMTP id 5B6A4F2E33; Sat, 11 Sep 2004 15:43:29 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15744-01-5; Sat, 11 Sep 2004 15:43:29 -0400 (EDT) Received: by nile.gnat.com (Postfix, from userid 1345) id 1B29DF2E3A; Sat, 11 Sep 2004 15:43:29 -0400 (EDT) From: Paul Hilfinger To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [commit] Move hex_string et.al. to defs.h / utils.c Message-Id: <20040911194329.1B29DF2E3A@nile.gnat.com> Date: Sat, 11 Sep 2004 19:43:00 -0000 X-Virus-Scanned: by amavisd-new at nile.gnat.com X-SW-Source: 2004-09/txt/msg00185.txt.bz2 > Somehow some some #include "language.h" were lost with PaulH's recent > *_string_custom cleanup. > Rather than add lots of those includes, I moved the hex_string and > hex_string_custom functions to utils.c, and the corresponding > declaration to defs.h. I also took the oportunity to improve the code a > little switching it to get_cell(). Andrew, Actually, the #includes were dropped deliberately, and you've done the piece what was SUPPOSED to happen and somehow got dropped: moving the decls to defs.h and defns to utils.c. Thanks. I must be careful not to overlook mere warnings (speaking of which, it would be a nice goal to remove all warnings from GDB compilations, lest they distract). > To answer your question about my thoughts on get_cell - I think it sux > less than the old code's local static buffer :-) It does make one long for fast GC, does it not? Or perhaps something region-based, where the region gets deallocated at, say, a point in the top-level command loop. Paul