From mboxrd@z Thu Jan 1 00:00:00 1970 From: Elena Zannoni To: Jim Blandy Cc: Elena Zannoni , Daniel Berlin , gdb-patches@sources.redhat.com Subject: Re: [RFA] linespec.c change to stop "malformed template specification" error Date: Thu, 07 Jun 2001 07:40:00 -0000 Message-id: <15135.37463.301545.370875@kwikemart.cygnus.com> References: <87ofsldrgr.fsf@dynamic-addr-83-177.resnet.rochester.edu> <15134.47162.825017.119342@kwikemart.cygnus.com> X-SW-Source: 2001-06/msg00123.html Jim Blandy writes: > > Elena Zannoni 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", 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 > > 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 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. >