From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12008 invoked by alias); 4 Aug 2004 09:04:34 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 11487 invoked from network); 4 Aug 2004 09:04:28 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sourceware.org with SMTP; 4 Aug 2004 09:04:28 -0000 Received: from localhost (localhost [127.0.0.1]) by nile.gnat.com (Postfix) with ESMTP id 02D7CF29BC; Wed, 4 Aug 2004 05:04:25 -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 16939-01-9; Wed, 4 Aug 2004 05:04:25 -0400 (EDT) Received: by nile.gnat.com (Postfix, from userid 1345) id B2400F2A00; Wed, 4 Aug 2004 05:04:25 -0400 (EDT) From: Paul Hilfinger To: Andrew Cagney Cc: brobecker@gnat.com, gdb@sources.redhat.com Subject: Re: Ada's formats Message-Id: <20040804090425.B2400F2A00@nile.gnat.com> Date: Wed, 04 Aug 2004 09:04:00 -0000 X-Virus-Scanned: by amavisd-new at nile.gnat.com X-SW-Source: 2004-08/txt/msg00021.txt.bz2 Andrew, You wrote: > Can "we" (I hate this abuse of the Queens English) delete the existing, > broken code then? With that resolved, its possible to move onto the next > Ada problem. Joel wrote: > Could you explain which part of the code you're refering to? You then wrote: > Uses of the struct language_format_info in core GDB (which > translates to local_.*_format macros). Rip that out and I suspect that > you'll find adding ada's formatting using method rather than > printf formats is trivial. I've finally been able to look at this seriously, and am afraid we're still not clear on what is "broken" that needs fixing. AFAICS, the language_format_info approach generally works in a purely functional sense, and back when we (briefly) used it to apply Ada's language formats for hex and octal strings, it worked just fine for us. (Currently, I see that m2-lang.c and scm-lang.c use non-C-like values for their language_format_info entries; is the mechanism working for them?) So I am assuming that you are referring mainly to a bogosity in the design aesthetics. I am willing to do the necessary cleanup here as community service, even though we have no need of it for the Ada language module, but first I would like to make quite sure I have a clear picture of what your idea of the right solution is. Is it simply a matter of replacing the language_format_info format strings with functions, or did you have something else entirely in mind? Paul