From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8211 invoked by alias); 11 Sep 2004 02:40:37 -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 8201 invoked from network); 11 Sep 2004 02:40:36 -0000 Received: from unknown (HELO tully.CS.Berkeley.EDU) (128.32.153.227) by sourceware.org with SMTP; 11 Sep 2004 02:40:36 -0000 Received: from tully.CS.Berkeley.EDU (localhost [127.0.0.1]) by tully.CS.Berkeley.EDU (8.12.7/8.12.7/3.141592645) with ESMTP id i8B2eX2Y018840; Fri, 10 Sep 2004 19:40:33 -0700 (PDT) Received: from tully.CS.Berkeley.EDU (hilfingr@localhost) by tully.CS.Berkeley.EDU (8.12.7/8.12.7/Submit) with ESMTP id i8B2eXel018837; Fri, 10 Sep 2004 19:40:33 -0700 (PDT) Message-Id: <200409110240.i8B2eXel018837@tully.CS.Berkeley.EDU> To: Andrew Cagney cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] patch to remove language-dependent numeric output support Reply-To: Hilfinger@CS.Berkeley.EDU In-reply-to: Your message of Fri, 10 Sep 2004 22:09:51 -0400. <41425E6F.4050607@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18833.1094870432.1@tully.CS.Berkeley.EDU> Date: Sat, 11 Sep 2004 02:40:00 -0000 From: Paul Hilfinger X-SW-Source: 2004-09/txt/msg00178.txt.bz2 > Just some notes though: > > (local_decimal_format_custom): Remove. > > > > * utils.c: (int_string): New function. > I suspect that the the blank lines aren't needed - blank lines separate > commits rather than separate parts of the same commit - whichever. Really? OK. Actually, I was putting in blank lines just to break up a long ChangeLog entry, but if there's actually a convention, I'm happy to follow it. > > functions. We have to split this up into separate print > > - statements because local_hex_string returns a local static > > + statements because hex_string returns a local static > > can you file a bug report - that pre-existing behavior is a recipe for > desaster :-( And what do you think of the get_cell mechanism in utils.c? Actually, I had considered changing the interface for that reason into something like: hex_string (buffer, value) and have hex_string return the result it puts into BUFFER (and likewise for other functions, mutatis mutandis). This would require each hex_string client to supply the return space. > Makefile.in will eventually need an update. If you want to do it > there's a script (gdb_makefile.in) hanging off of the ari web page that > you might find useful. Fixing the file is obvious. > I suspect that the special Makefile rule for printcmd.o can be deleted - > something for later. Ditto. Oops. I had, in fact, intended to do this. > Again, thanks. Now where were we with Ada. That's a good question. The only thing I've heard about at the moment is that Joel mentioned that you had said something about the architecture vector for language-specific types (I believe it was). I have got a patch for getting Ada to handle that the way C now does. However, in the process, I've come up with a question about intended use: Suppose one is in the evaluation code for language X and wants to use built-in type FOO defined for language X. What is the preferred way to do so? Calling language_lookup_primitive_type_by_name? Seems a shame to conduct a search in language-specific code when you know the offset in that language's type vector: is that how we're supposed to do it instead, using values from an enumerated type such as enum c_primitive_types? Anyway, I can see several ways to do it, but the intent is a little unclear. Paul