From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: Daniel Berlin <dan@cgsoftware.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] linespec.c change to stop "malformed template specification" error
Date: Wed, 06 Jun 2001 21:00:00 -0000
Message-id: <npg0dd2b20.fsf@zwingli.cygnus.com>
References: <87ofsldrgr.fsf@dynamic-addr-83-177.resnet.rochester.edu> <15134.47162.825017.119342@kwikemart.cygnus.com>
X-SW-Source: 2001-06/msg00106.html

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.

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.