From: David Carlton <carlton@math.stanford.edu>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [drow-cplus-branch] handle namespace scope
Date: Thu, 21 Nov 2002 12:29:00 -0000 [thread overview]
Message-ID: <ro1k7j6is3s.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <20021121174010.GA12554@nevyn.them.org>
On Thu, 21 Nov 2002 12:40:10 -0500, Daniel Jacobowitz <drow@mvista.com> said:
> On Tue, Nov 19, 2002 at 03:07:45PM -0800, David Carlton wrote:
>> Okay to commit?
> The idea is sound, some nits...
>> @@ -485,21 +483,36 @@ finish_block (struct symbol *symbol, str
>> const char *name = SYMBOL_CPLUS_DEMANGLED_NAME (symbol);
>> const char *next;
>>
>> - for (next = cp_find_first_component (name);
>> - *next == ':';
>> - /* The '+ 2' is to skip the '::'. */
>> - next = cp_find_first_component (next + 2))
>> +if (processing_has_namespace_info)
> Mailer/patch glitch? Careful of your indentation.
Whoops, thanks, that was a cut/paste problem. Sorry about that.
>> + for (current = name, next = cp_find_first_component (current);
>> + *next == ':';
>> + /* The '+ 2' is to skip the '::'. */
>> + current = next,
>> + next = cp_find_first_component (current + 2))
>> + ;
> I see that you're just moving this bit but I should have commented on
> it last time: please do not use for loops this way. Something like:
> current = name;
> next = cp_find_first_component (current);
> while (*next == ':')
> {
> current = next;
> /* The '+ 2' is to skip the '::'. */
> *next = cp_find_first_component (current + 2);
> }
> In general, if all the work is inside the parentheses a for loop is
> inappropriate.
Will do; that's probably not the only place I should fix this.
> I did not extensively examine your lookup_symbol_* changes in this
> patch; I eyeballed them and they looked good but that's it. That's
> enough for me while you're still evolving this.
Great, thanks. Yeah, that really is in flux: I'm starting to
understand what the underlying conceptual issues are, but I still
haven't gotten those nailed down properly. And even once I do have
them nailed down properly, there are implementations details: e.g. the
lookup_symbol stuff does too much temporary allocation of copies via
xmalloc, which I suspect I'll want to eventually replace either by
temporary allocation on an obstack (or via alloca, maybe), or else
rewrite the code so that it doesn't need to make copies at all.
I'll commit it with the two fixes you mentioned, and I'll also look
for other loops that I should rewrite for clarity before committing.
Thanks,
David Carlton
carlton@math.stanford.edu
next prev parent reply other threads:[~2002-11-21 20:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-19 15:07 David Carlton
2002-11-21 9:40 ` Daniel Jacobowitz
2002-11-21 12:29 ` David Carlton [this message]
2002-11-22 9:18 ` David Carlton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ro1k7j6is3s.fsf@jackfruit.Stanford.EDU \
--to=carlton@math.stanford.edu \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox