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 23233 invoked from network); 11 Nov 2002 23:22:38 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 11 Nov 2002 23:22:38 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id gABNMWY21137; Mon, 11 Nov 2002 15:22:32 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Elena Zannoni Cc: gdb-patches@sources.redhat.com, Fernando Nasser , Jim Blandy Subject: Re: [rfa] linespec.c, part 3 References: <15824.12061.128364.623571@localhost.redhat.com> From: David Carlton Date: Mon, 11 Nov 2002 17:15:00 -0000 In-Reply-To: <15824.12061.128364.623571@localhost.redhat.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/msg00332.txt.bz2 On Mon, 11 Nov 2002 17:28:45 -0500, Elena Zannoni said: > David Carlton writes: >> This part of the decode_line_1 refactoring moves some code >> initializing some flags into a separate function set_flags. Some >> comments: > Looks ok, but I have a question. Wouldn't the code that sets up > has_comma and is_quote_enclosed also belong to this set_flags > function? It seems entirely plausible to me that that is the case. For now, that will come in my next patch, which won't quite do what you ask: the problem is that that part of the code is also updating 'p' to figure out where a compound linespec separator is (for filenames or C++/Java objects). Teasing this apart is a bit of a mess; my current "final" version of these changes has 'has_comma' buried in an internal function, and 'is_quote_enclosed' doesn't last for very long. But it's messy, so I think that, once I'm done submitting patches that just break off code into separate functions, we should revisit this issue. > (Ideally a struct of flags could be set up). Yes, that would be a much better idea than passing the flag variables by reference. > But this is for a separate patch, you are just moving code around > now. Right. > go ahead, thanks! Committed. (Now you've caught up to me! Eek! I'll have to get my grading done quickly so I can keep up my end of things. :-) ) David Carlton carlton@math.stanford.edu