From: Daniel Berlin <dan@cgsoftware.com>
To: Jim Blandy <jimb@zwingli.cygnus.com>
Cc: Daniel Berlin <dan@cgsoftware.com>,
Elena Zannoni <ezannoni@cygnus.com>,
gdb-patches@sources.redhat.com
Subject: Re: [RFA] linespec.c change to stop "malformed template specification" error
Date: Thu, 07 Jun 2001 11:35:00 -0000 [thread overview]
Message-ID: <87bso0nno7.fsf@cgsoftware.com> (raw)
In-Reply-To: <np3d9c17c8.fsf@zwingli.cygnus.com>
Jim Blandy <jimb@zwingli.cygnus.com> writes:
> Daniel Berlin <dan@cgsoftware.com> writes:
>> > So finding breakpoint names requires parsing (almost) arbitrary
>> > expressions.
>> Only if you allow arbitrary names.
>> We don't.
>> So this leaves allowing a superset.
>
> Sorry, I don't understand what you mean.
We don't allow expressions inside the line specifications right now.
Try "break (5 < 10) ? 10 : 20".
So the trouble we run into right now is because due to us wanting to
do good error messages, without any kind of a real parser, we
sometimes incorrectly split out what the function name is from the rest of the
line specification.
The solution to this is to allow a superset of what we do now (or use
a real parser, i have one ready if we like), at the expense of error messages.
Right now, we don't accept things we should. We'd be better off
accepting things we shouldn't (ie Daniel<int::fred), and complaining
that we couldn't find "Daniel<int", then we would not accepting
something like "Daniel<int, int>::fred", which is what we do now,
because of the problem in find_toplevel_char.
If you want to allow arbitrary expressions inside line specifications,
well, that's a whole nother can of worms.
I'm trying to solve the problem above (that we incorrectly parse the
linespec typed in, in the form of incorrectly determining what part is
the function name, if there is one). You seem to be saying the
solution won't work because it'll break arbitrary expressions in
names.
But we don't support arbitrary expressions in names *anyway*.
It's like saying "if you do this to the car, it won't be able to
hover." when the car can't hover anyway.
:)
If we want to discuss doing proper evaluation of the expressions that
may occur in a linespec, then lets do that. But that's not what my
patch was intending to solve.
--
"One time I went to a museum where all the work in the museum had
been done by children. They had all the paintings up on
refrigerators.
"-Steven Wright
next prev parent reply other threads:[~2001-06-07 11:35 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-22 14:06 Daniel Berlin
2001-06-06 16:09 ` Elena Zannoni
2001-06-06 17:00 ` Fernando Nasser
2001-06-06 21:00 ` Jim Blandy
2001-06-06 22:09 ` Daniel Berlin
2001-06-07 8:40 ` Jim Blandy
2001-06-07 8:47 ` macro-expanding expressions in GDB Jim Blandy
2001-06-07 9:01 ` Daniel Berlin
2001-06-07 11:52 ` Jim Blandy
2001-06-07 12:04 ` Daniel Berlin
2001-06-07 11:16 ` Stan Shebs
2001-06-06 23:36 ` [RFA] linespec.c change to stop "malformed template specification" error Daniel Berlin
2001-06-07 6:00 ` Fernando Nasser
2001-06-07 9:09 ` Jim Blandy
2001-06-07 7:40 ` Elena Zannoni
[not found] ` <nppucg1eq5.fsf@zwingli.cygnus.com>
2001-06-07 9:13 ` Daniel Berlin
2001-06-07 11:18 ` Jim Blandy
2001-06-07 11:35 ` Daniel Berlin [this message]
2001-06-07 15:22 ` Jim Blandy
2001-06-07 16:40 ` Daniel Berlin
2001-06-07 10:27 ` Elena Zannoni
2001-06-07 12:30 ` Fernando Nasser
2001-06-07 15:14 ` Jim Blandy
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=87bso0nno7.fsf@cgsoftware.com \
--to=dan@cgsoftware.com \
--cc=ezannoni@cygnus.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@zwingli.cygnus.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