This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] fix pre-/post- in-/decrement
- From: Ken Werner <ken at linux dot vnet dot ibm dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Joel Brobecker <brobecker at adacore dot com>, Daniel Jacobowitz <dan at codesourcery dot com>, Ulrich Weigand <uweigand at de dot ibm dot com>, gdb-patches at sourceware dot org
- Date: Tue, 2 Nov 2010 09:23:34 +0100
- Subject: Re: [patch] fix pre-/post- in-/decrement
- References: <201010041301.o94D1QHV032611@d12av02.megacenter.de.ibm.com> <m3vd55apf7.fsf@fleche.redhat.com> <201010190938.35120.ken@linux.vnet.ibm.com>
On Tuesday, October 19, 2010 9:38:34 am Ken Werner wrote:
> On Wednesday, October 13, 2010 9:00:28 pm Tom Tromey wrote:
> > Ken> I don't see how to control the type of the result of an operator
> > Ken> there. I'm still quite new to the GDB parsing internals and would
> > Ken> appreciate any insights.
> >
> > It is probably a bit of a pain, since the IR generated by the parser is
> > a bit unusual (as compilers go).
> >
> > However, it seems to me that it would be much friendlier for users to
> > report this as a parse error rather than a runtime error.
> >
> > One option would be to write a C/C++ implementation of the language_defn
> > la_post_parser method, which would look at the expression to see if this
> > constraint is violated.
> >
> > Another option would be to try to implement it in the grammar.
>
> Ok - I see. Thanks for your suggestions. This seems to be something bigger
> and could be implemented as part of a future patch :). I think for now the
> non- language dependent parts of the patch would be sufficient.
> The attached patch only contains the fix for the post in-/decrement
> operators as this is what the vec_unop patch
> (http://sourceware.org/ml/gdb-
> patches/2010-10/msg00031.html) prevents from going upstream.
> Tested on i686-*-linux-gnu with no regressions.
> OK to apply?
Ping. : )
Regards
Ken