This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] linespec.c change to stop "malformed template specification" error
- To: Jim Blandy <jimb at cygnus dot com>
- Subject: Re: [RFA] linespec.c change to stop "malformed template specification" error
- From: Elena Zannoni <ezannoni at cygnus dot com>
- Date: Thu, 7 Jun 2001 10:40:23 -0400
- Cc: Elena Zannoni <ezannoni at cygnus dot com>, Daniel Berlin <dan at cgsoftware dot com>, gdb-patches at sources dot redhat dot com
- References: <87ofsldrgr.fsf@dynamic-addr-83-177.resnet.rochester.edu><15134.47162.825017.119342@kwikemart.cygnus.com><npg0dd2b20.fsf@zwingli.cygnus.com>
Jim Blandy writes:
>
> Elena Zannoni <ezannoni@cygnus.com> writes:
> > Daniel Berlin writes:
> > > This error is cause by find_toplevel_char not knowing that '<' and '>'
> > > increase and decrease the depth we are at.
> > >
> > > The result is that if you say "break _Rb_tree<int, int>", when it goes
> > > to look for a comma at the top level, it thinks it found one right
> > > after the "int", and temporarily truncates the string to '_Rb_tree<int,'
> > > When we then proceed to go through the string, we see the "<", and
> > > then go to find the end of the template name, and can't, because we've
> > > truncated the string in the wrong place, and issue an error.
> > >
> > > Cute, no?
> > >
> > > --Dan
> > >
> >
> > Seems OK to me, but could you update the comment on top of the
> > find_toplevel_char() to reflect that the char is looked for also
> > outside of '<' and '>' pairs?
> >
> > Any of the other maintainers (Jim, Fernando) has any comments?
>
> Operators like '<' can appear in template arguments. For example, you
> could define a template like this:
>
> template <int i> struct list { int a[i], b[i]; };
>
> and then use it like this:
>
> struct list <20> l;
>
> and you get the same thing as if you'd written:
>
> struct { int a[20], b[20]; } l;
>
> At least I think so, anyway. I don't really know C++. But the point
> is, those template arguments can be any arbitrary constant expression.
> So I could have a template invocation like this:
>
> struct list < (x < y) ? 10 : 20 > l;
>
> So how does our poor little decode_line_1 handle that? Basically, we
> need to replace decode_line_1 with a real parser.
I am not sure that decode_line_1 will ever be invoked in such a case.
Looking at when it's called, it seems to be only when you specify
a location, not an expression, and that occurs for 'break blah' and
'list blah' only. Also, find_toplevel_char is called only when looking
for a comma, so even with your example it should still work fine,
even though the 'depth' variable will have an inaccurate value.
But yes, I agree, decode_line_1 is a mess.
Elena
>
> In the mean time, however, I think it's more important to recognize
> the template argument brackets at all than to handle template
> arguments that contain < and > operators.
>
> So with this caveat, I think the change is fine.
>