From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Received: (qmail 17114 invoked from network); 11 Nov 2002 23:18:05 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 11 Nov 2002 23:18:05 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id gABNHvb21119; Mon, 11 Nov 2002 15:17:57 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Klee Dienes Cc: Jim Blandy , Fernando Nasser , Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [rfa] linespec.c, part 3 References: <35E8C110-F5C5-11D6-AA35-00039396EEB8@apple.com> From: David Carlton Date: Mon, 11 Nov 2002 17:15:00 -0000 In-Reply-To: <35E8C110-F5C5-11D6-AA35-00039396EEB8@apple.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-11/txt/msg00331.txt.bz2 On Mon, 11 Nov 2002 17:30:41 -0500, Klee Dienes said: > The linespec.c changes you posted looked so cool, we couldn't resist > using them. Great! I would seem to have fans everywhere. :-) > One issue that came up was that the part of our code that decodes an > Objective-C function needs to have the if-clause removed from the > breakpoint expression (since Objective-C functions can contain > spaces). We did this by extending set_flags to pass back a pointer > to the if-clause, if there was one, and by splitting decode_line_1 > into two functions, one of which sets the defaults, calls set_flags, > strips off the if-clause and calls decode_line_2, which does the > actual parsing. I think that's pretty sensible. I don't care too much one way or another as to whether or not there's a separate 'decode_line_2' function to do the parsing, but the general idea of setting various necessary flags first before doing any decoding sounds good to me. For now, I want to worry about breaking up the existing code into separate functions first (I'm already giving Elena enough to worry about as it is, I think), but it sounds like, once that phase is done and we can actually understand what decode_line_1 is doing, we'll want to start rewriting functions, changing the existing reorganization. So hold off on your patch until then, and then we can talk. David Carlton carlton@math.stanford.edu