From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: PATCH: Make gdbserver use async I/O on Linux Date: Thu, 07 Jun 2001 10:43:00 -0000 Message-id: <20010607104346.B19961@nevyn.them.org> References: <20010606140322.A29266@nevyn.them.org> X-SW-Source: 2001-06/msg00138.html On Thu, Jun 07, 2001 at 09:36:23AM +0300, Eli Zaretskii wrote: > > On Wed, 6 Jun 2001, Daniel Jacobowitz wrote: > > > The only problem I can think of that this might cause is if F_SETOWN is less > > portable than FASYNC. > > Exactly. And that is why I'd suggest to make this change conditioned > on F_SETOWN being defined. Easy enough. How about this, then? -- Daniel Jacobowitz Debian GNU/Linux Developer Monta Vista Software Debian Security Team >From dan@www.cgsoftware.com Thu Jun 07 11:06:00 2001 From: Daniel Berlin To: Elena Zannoni Cc: Jim Blandy , Subject: Re: [RFA] linespec.c change to stop "malformed template specification"error Date: Thu, 07 Jun 2001 11:06:00 -0000 Message-id: References: <15135.47501.950878.977558@kwikemart.cygnus.com> X-SW-Source: 2001-06/msg00139.html Content-length: 2872 On Thu, 7 Jun 2001, Elena Zannoni wrote: > Jim Blandy writes: > > > > Elena Zannoni writes: > > > > 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. > > > > Templates can expand to functions, too: > > > > Ok, I was looking at your example in a myopic way. > > > template > > int add_const (int j) > > { > > return i + j; > > } > > > > then, add_const <4> (3) returns 7. > > > > But add_const <4> and add_const <5> are different functions. The > > compiler emits separate code for each of them. So you need to be able > > to set a breakpoint on add_const <4>. And the template argument to > > add_const can be any constant expression. > > > > So finding breakpoint names requires parsing (almost) arbitrary expressions. > > > > Yes, you are correct. That function (find_toplevel_char) would get it wrong > if we had something like this, even with Dan's patch: > > break foo_classy ? 1 : 2, 4>::foo > This isn't relevant, since it won't work now anyway. We never evaluate the expressions involved in decode_line_1. We just want to get names. Try "break (1 < 0):10 ? 5" It won't breakpoint line 10 or 5, you'll get an error. ;) This is because we don't ever use the expression evaluator on the expressions involved. Line specifications aren't part of the expression syntax. If they were, we'd just be able to use the language parsers and be done with it. It would also mean "print :" would work. > It would think that the greater-than was the end of the template, and > that the ',' was outside of the template specification. But, if that > is a legal expression (I am not sure), how likely would it be? > Definitely better with Dan's patch than w/o, at least we can catch the > simpler cases. > > Elena > ~