This is the mail archive of the
mailing list for the GDB project.
Re: [patch] fix pre-/post- in-/decrement
- From: Daniel Jacobowitz <dan at codesourcery dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Ken Werner <ken at linux dot vnet dot ibm dot com>, gdb-patches at sourceware dot org, Joel Brobecker <brobecker at adacore dot com>, Vladimir Prus <vladimir at codesourcery dot com>
- Date: Tue, 5 Oct 2010 09:42:01 -0400
- Subject: Re: [patch] fix pre-/post- in-/decrement
- References: <20101005011650.GF6985@caradoc.them.org> <201010051328.o95DSJ8L027985@d12av02.megacenter.de.ibm.com>
On Tue, Oct 05, 2010 at 03:28:19PM +0200, Ulrich Weigand wrote:
> Daniel Jacobowitz wrote:
> > On Tue, Oct 05, 2010 at 01:24:51AM +0200, Ulrich Weigand wrote:
> > > - If you execute "set *$p = *$q = 0" and the write to *$q fails,
> > > do you really expect *$p to be set to the old value of *$q
> > > instead of to 0?
> > Yes, I would expect that. To me, this is roughly "the debugger treats
> > all pointers as volatile".
> The thing is, I had interpreted the C standard to read that even if
> pointers p and q *are* volatile, a statement like "*p = *q = 0" would
> still just trigger two writes, and no reads.
You're right, I remember Nathan's recent arguments about this on
> "Assignments are also expressions and have an rvalue. However when assigning
> to a scalar volatile, the volatile object is not reread, regardless of whether
> the assignment expression's rvalue is used or not. If the assignment's rvalue
> is used, the value is that assigned to the volatile object. [...] If you need
> to read the volatile object after an assignment has occurred, you must use a
> separate expression with an intervening sequence point."
> To reduce the potential for confusion, it seems to me GDB ought to mirror
> that behavior as well ...
It seems to me that this is a disruptive change for us, because the "a
= b" case is more likely to be used than anything fancy (a += b, a = b
= c). If we change it, we should document the change.
Vladimir, would this interact with your recent varobj changes? We
worked out exactly which reads we wanted, but I don't remember if
value_assign is involved.