Re: Arithmetic assignment side-effects

2013-08-06 Thread Chet Ramey
On 8/5/13 10:57 PM, DJ Mills wrote: > On Sun, Aug 4, 2013 at 4:41 PM, Andreas Schwab wrote: > >> Chris Down writes: >> >> x+=a is the same as x=x+a. Now replace a by (x=1) and it becomes >> obvious that 1 is a perfectly valid outcome. >> >> > I still don't see that; for one thing even with: > >

Re: Arithmetic assignment side-effects

2013-08-06 Thread Andreas Schwab
Dan Douglas writes: > Evaluating the expression on the RHS Now do that strictly from left to right. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."

Re: Arithmetic assignment side-effects

2013-08-06 Thread DJ Mills
On Tue, Aug 6, 2013 at 3:20 AM, Andreas Schwab wrote: > DJ Mills writes: > > > I still don't see that; > > Go strictly from left to right. > > It doesn't make any kind of logical sense to do so. Yes, then the "(x = 1)" would be evaluated last, but how do you evaluate the entire statement, for th

Re: Arithmetic assignment side-effects

2013-08-06 Thread Dan Douglas
On Tuesday, August 06, 2013 09:20:38 AM Andreas Schwab wrote: > DJ Mills writes: > > > I still don't see that; > > Go strictly from left to right. How do you assign something that hasn't been evaluated yet? Evaluating the expression on the RHS is an absolute prerequisite to evaluating the assi

Re: Arithmetic assignment side-effects

2013-08-06 Thread Andreas Schwab
DJ Mills writes: > I still don't see that; Go strictly from left to right. > gcc agrees with me. No, it doesn't. > Especially with the parens there, Parens have no effect at all. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 21

Re: Arithmetic assignment side-effects

2013-08-05 Thread DJ Mills
On Sun, Aug 4, 2013 at 4:41 PM, Andreas Schwab wrote: > Chris Down writes: > > x+=a is the same as x=x+a. Now replace a by (x=1) and it becomes > obvious that 1 is a perfectly valid outcome. > > I still don't see that; for one thing even with: #include int main(void) { int x = 0; printf("

Re: Arithmetic assignment side-effects

2013-08-05 Thread DJ Mills
On Sun, Aug 4, 2013 at 9:08 PM, Linda Walsh wrote: > > > Chris Down wrote: > >> Yes, I agree, it becomes ambiguous when described in this fashion. I >> think the >> aesthetics of x+=y vs x=x+y are important here. >> > > From the bash manpage, it would see that += is higher precedence > than assig

Re: Arithmetic assignment side-effects

2013-08-05 Thread Andreas Schwab
Dan Douglas writes: > = and += have equal precedence. Associativity is right to left, as described > in > operator(7). x=1 occurs first. Associativity doesn't define evaluation order, only how the expression is parsed. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint =

Re: Arithmetic assignment side-effects

2013-08-04 Thread Linda Walsh
Dan Douglas wrote: On Sunday, August 04, 2013 06:08:18 PM Linda Walsh wrote: From the bash manpage, it would see that += is higher precedence than assignment, so the increment would be done first, followed by the attempt at an assignment of 1 to 1. = and += have equal precedence. Associativi

Re: Arithmetic assignment side-effects

2013-08-04 Thread Dan Douglas
On Sunday, August 04, 2013 06:08:18 PM Linda Walsh wrote: > From the bash manpage, it would see that += is higher precedence > than assignment, so the increment would be done first, followed > by the attempt at an assignment of 1 to 1. = and += have equal precedence. Associativity is right to left

Re: Arithmetic assignment side-effects

2013-08-04 Thread Linda Walsh
Chris Down wrote: Yes, I agree, it becomes ambiguous when described in this fashion. I think the aesthetics of x+=y vs x=x+y are important here. From the bash manpage, it would see that += is higher precedence than assignment, so the increment would be done first, followed by the attempt at a

Re: Arithmetic assignment side-effects

2013-08-04 Thread Chris Down
On 2013-08-04 22:41, Andreas Schwab wrote: > x+=a is the same as x=x+a. In most cases I'd agree, in this case I think it changes the logic when considering += as an atomic increment (which, of course, += isn't, but aesthetically it presents itself as such) as opposed to two separate operations. >

Re: Arithmetic assignment side-effects

2013-08-04 Thread Andreas Schwab
Chris Down writes: > On 2013-08-03 17:04, Dan Douglas wrote: >> Is it specified what the value of x should be after this expression? >> >> x=0; : $((x+=x=1)) > > I don't know if it is specified in a standard (I suspect it may be undefined), > but it looks pretty clear to me that the answer should

Re: Arithmetic assignment side-effects

2013-08-04 Thread Chris Down
On 2013-08-03 17:04, Dan Douglas wrote: > Is it specified what the value of x should be after this expression? > > x=0; : $((x+=x=1)) I don't know if it is specified in a standard (I suspect it may be undefined), but it looks pretty clear to me that the answer should be 2. Has anyone proposed logi