Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #64878 > unrolled thread
| Started by | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| First post | 2015-07-07 14:44 -0700 |
| Last post | 2015-07-07 22:30 -0400 |
| Articles | 20 on this page of 131 — 17 participants |
Back to article view | Back to comp.lang.c
Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-07 14:44 -0700
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-07 15:34 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-08 08:47 -0700
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-08 09:11 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-08 10:24 -0700
Re: Unspecified behavior in C John Bode <jfbode1029@gmail.com> - 2015-07-08 10:46 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-08 13:54 -0400
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-08 11:12 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-09 09:15 -0700
Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 17:33 +0100
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-10 09:24 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-10 12:54 -0400
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-09 10:58 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-10 09:33 -0700
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-10 12:11 -0700
Re: Unspecified behavior in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 21:05 +0000
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-10 17:14 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-11 09:32 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-11 12:59 -0400
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-11 17:21 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-11 09:23 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-11 13:03 -0400
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-11 17:15 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-12 09:52 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-12 14:13 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-13 09:02 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-13 13:18 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-13 11:09 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-13 15:06 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 08:14 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-14 12:02 -0400
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-13 12:03 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 07:54 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-14 11:16 -0400
Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-14 16:17 +0100
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 09:16 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-14 12:29 -0400
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-14 14:57 -0400
Re: Unspecified behavior in C Öö Tiib <ootiib@hot.ee> - 2015-07-14 13:12 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-14 16:30 -0400
Re: Unspecified behavior in C Öö Tiib <ootiib@hot.ee> - 2015-07-14 15:54 -0700
Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-14 21:41 -0500
Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-14 21:51 -0500
Re: Unspecified behavior in C Öö Tiib <ootiib@hot.ee> - 2015-07-15 12:42 -0700
Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-15 16:13 -0500
Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-16 08:49 -0500
Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 10:10 -0700
Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-20 13:24 -0500
Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 02:56 -0700
Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-23 11:26 -0500
Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-26 11:24 -0700
Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-23 19:03 -0500
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 21:19 -0700
Re: Unspecified behavior in C Martin Shobe <martin.shobe@yahoo.com> - 2015-07-15 23:45 -0500
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-16 01:37 -0400
Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-16 09:42 +0100
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:05 -0700
Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:32 +0100
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-16 21:07 -0400
We're good - don't you worry 'bout a thing, babe (Was: Unspecified behavior in C) gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-17 07:21 +0000
Re: Unspecified behavior in C raltbos@xs4all.nl (Richard Bos) - 2015-07-19 20:59 +0000
Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-19 22:02 +0100
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-16 17:59 -0400
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-16 23:09 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-17 18:48 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-17 23:09 -0400
Re: Unspecified behavior in C raltbos@xs4all.nl (Richard Bos) - 2015-07-19 20:57 +0000
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-19 17:22 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-19 18:57 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-19 22:16 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-19 19:30 -0700
Re: Unspecified behavior in C John Bode <jfbode1029@gmail.com> - 2015-07-30 14:20 -0700
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-30 15:30 -0700
Re: Unspecified behavior in C John Bode <jfbode1029@gmail.com> - 2015-07-30 15:53 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-30 16:46 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-31 00:59 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-31 17:15 -0700
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-31 18:28 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-31 23:28 -0400
Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 04:07 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-08-04 18:02 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-04 21:27 -0400
Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-24 09:33 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-08-24 17:11 -0700
Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 12:44 -0700
Re: Unspecified behavior in C Ken Brody <kenbrody@spamcop.net> - 2015-08-03 12:09 -0400
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-03 13:26 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-08-03 17:53 -0700
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-08-03 18:44 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-08-04 17:59 -0700
Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-08-05 02:23 +0100
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-04 21:39 -0400
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-08-04 19:27 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-04 00:25 -0400
Re: Unspecified behavior in C Ken Brody <kenbrody@spamcop.net> - 2015-08-04 11:55 -0400
Re: Unspecified behavior in C Philip Lantz <prl@canterey.us> - 2015-08-04 10:31 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-04 13:32 -0400
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-04 22:46 -0400
Re: Unspecified behavior in C Ken Brody <kenbrody@spamcop.net> - 2015-08-10 12:16 -0400
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-10 13:26 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-08-03 17:46 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-05 12:34 -0400
Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-14 17:57 +0100
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 10:31 -0700
Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-14 18:50 +0100
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 20:59 -0700
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-14 11:34 -0700
Re: Unspecified behavior in C raltbos@xs4all.nl (Richard Bos) - 2015-07-19 20:46 +0000
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-12 12:07 -0700
Re: Unspecified behavior in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 19:53 +0000
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-12 16:12 -0400
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-09 14:20 -0400
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-09 12:18 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-10 09:47 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-10 13:36 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-11 09:19 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-11 12:56 -0400
Re: Unspecified behavior in C gordonb.j19di@burditt.org (Gordon Burditt) - 2015-07-11 20:36 -0500
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-12 10:10 -0700
Re: Unspecified behavior in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 20:13 +0100
Re: Unspecified behavior in C raltbos@xs4all.nl (Richard Bos) - 2015-07-09 11:17 +0000
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-08 10:37 -0700
Re: Unspecified behavior in C John Bode <jfbode1029@gmail.com> - 2015-07-08 10:51 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-08 14:14 -0400
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-08 12:19 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-08 12:14 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-08 10:40 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-08 14:29 -0400
Re: Unspecified behavior in C raltbos@xs4all.nl (Richard Bos) - 2015-07-09 11:20 +0000
Re: Unspecified behavior in C Robert Wessel <robertwessel2@yahoo.com> - 2015-07-09 02:30 -0500
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-07 22:30 -0400
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-04 18:02 -0700 |
| Message-ID | <5ce66777-e0c9-47d2-ac53-33182dd079b0@googlegroups.com> |
| In reply to | #66845 |
On Tuesday, August 4, 2015 at 4:07:40 AM UTC-7, Tim Rentsch wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>
> > For example, the expression --p->mem[a]++
>
> The expression --p->mem[a]++ contains a constraint violation.
>
> > contains all of the the following 5 sub-expressions:
> > --p->mem[a] subscript expression
> > --p->mem member selection expression
> > a primary expression
> > --p pre-fix decrement expression
> > p primary expression
>
> And this isn't how it is parsed. The subexpressions are
>
> p
> a
> p->mem
> p->mem[a]
> p->mem[a]++
>
> which are proper subexpressions, and the entire original
> expression, which is a non-proper subexpression.
p
p->mem
a
p->mem[a]
p->mem[a]++
?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-04 21:27 -0400 |
| Message-ID | <mpromb$m9t$1@dont-email.me> |
| In reply to | #66895 |
On 08/04/2015 09:02 PM, David Kleinecke wrote: > On Tuesday, August 4, 2015 at 4:07:40 AM UTC-7, Tim Rentsch wrote: >> James Kuyper <jameskuyper@verizon.net> writes: >> >>> For example, the expression --p->mem[a]++ >> >> The expression --p->mem[a]++ contains a constraint violation. >> >>> contains all of the the following 5 sub-expressions: >>> --p->mem[a] subscript expression >>> --p->mem member selection expression >>> a primary expression >>> --p pre-fix decrement expression >>> p primary expression >> >> And this isn't how it is parsed. The subexpressions are >> >> p >> a >> p->mem >> p->mem[a] >> p->mem[a]++ >> >> which are proper subexpressions, and the entire original >> expression, which is a non-proper subexpression. Tim is correct, I was insufficiently careful putting together my example. > p > p->mem > a > p->mem[a] > p->mem[a]++ > > ? It's a rather important point that the C standard says that the evalation of a is sequenced before it's use as a subscript, but that it is unsequenced relative to the evaluations of p and p->mem. Therefore, your order is just as acceptable as Tim's. The order matters only if the relevant expressions have side effects, which would apply to 'p' and 'a' only if they were volatile-qualified. If so, those side-effects are unsequenced relative to any of the other evaluations in the [corrected version of] that expression, because it contains not a single sequence point. In a slightly more complicated expression, this is easier to see: (--p)->mem[++a]++ That expression has three different side-effects: --p, ++a, and the final ++. Because there are no sequence points in that expression, those side-effects are unsequenced relative to each other. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-24 09:33 -0700 |
| Message-ID | <kfn37z8zlwh.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66895 |
David Kleinecke <dkleinecke@gmail.com> writes: > On Tuesday, August 4, 2015 at 4:07:40 AM UTC-7, Tim Rentsch wrote: >> James Kuyper <jameskuyper@verizon.net> writes: >> >>> For example, the expression --p->mem[a]++ >> >> The expression --p->mem[a]++ contains a constraint violation. >> >>> contains all of the the following 5 sub-expressions: >>> --p->mem[a] subscript expression >>> --p->mem member selection expression >>> a primary expression >>> --p pre-fix decrement expression >>> p primary expression >> >> And this isn't how it is parsed. The subexpressions are >> >> p >> a >> p->mem >> p->mem[a] >> p->mem[a]++ >> >> which are proper subexpressions, and the entire original >> expression, which is a non-proper subexpression. > > p > p->mem > a > p->mem[a] > p->mem[a]++ > > ? My list was simply listing the subexpressions, in no particular order. If your question is meant to ask about order of evaluation, there is no rule about whether 'a' is evaluated first or 'p->mem' is evaluated first.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-24 17:11 -0700 |
| Message-ID | <97a751b7-9789-4d2b-8338-65566805805d@googlegroups.com> |
| In reply to | #68243 |
On Monday, August 24, 2015 at 9:33:45 AM UTC-7, Tim Rentsch wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > > On Tuesday, August 4, 2015 at 4:07:40 AM UTC-7, Tim Rentsch wrote: > >> James Kuyper <jameskuyper@verizon.net> writes: > >> > >>> For example, the expression --p->mem[a]++ > >> > >> The expression --p->mem[a]++ contains a constraint violation. > >> > >>> contains all of the the following 5 sub-expressions: > >>> --p->mem[a] subscript expression > >>> --p->mem member selection expression > >>> a primary expression > >>> --p pre-fix decrement expression > >>> p primary expression > >> > >> And this isn't how it is parsed. The subexpressions are > >> > >> p > >> a > >> p->mem > >> p->mem[a] > >> p->mem[a]++ > >> > >> which are proper subexpressions, and the entire original > >> expression, which is a non-proper subexpression. > > > > p > > p->mem > > a > > p->mem[a] > > p->mem[a]++ > > > > ? > > My list was simply listing the subexpressions, in no > particular order. If your question is meant to ask > about order of evaluation, there is no rule about > whether 'a' is evaluated first or 'p->mem' is evaluated > first. That was the way it would be parsed which the discussion was about.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-06 12:44 -0700 |
| Message-ID | <kfnlhcjtjs6.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #68279 |
David Kleinecke <dkleinecke@gmail.com> writes: > On Monday, August 24, 2015 at 9:33:45 AM UTC-7, Tim Rentsch wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: >> >>> On Tuesday, August 4, 2015 at 4:07:40 AM UTC-7, Tim Rentsch wrote: >>>> James Kuyper <jameskuyper@verizon.net> writes: >>>> >>>>> For example, the expression --p->mem[a]++ >>>> >>>> The expression --p->mem[a]++ contains a constraint violation. >>>> >>>>> contains all of the the following 5 sub-expressions: >>>>> --p->mem[a] subscript expression >>>>> --p->mem member selection expression >>>>> a primary expression >>>>> --p pre-fix decrement expression >>>>> p primary expression >>>> >>>> And this isn't how it is parsed. The subexpressions are >>>> >>>> p >>>> a >>>> p->mem >>>> p->mem[a] >>>> p->mem[a]++ >>>> >>>> which are proper subexpressions, and the entire original >>>> expression, which is a non-proper subexpression. >>> >>> p >>> p->mem >>> a >>> p->mem[a] >>> p->mem[a]++ >>> >>> ? >> >> My list was simply listing the subexpressions, in no >> particular order. If your question is meant to ask >> about order of evaluation, there is no rule about >> whether 'a' is evaluated first or 'p->mem' is evaluated >> first. > > That was the way it would be parsed which the discussion was about. Apparently we are using the term "how it is parsed" in different ways. What I meant is only what rules of grammar apply, not the behavior of some putative parsing algorithm. The first is well-defined, the second depends on what algorithm is used.
[toc] | [prev] | [next] | [standalone]
| From | Ken Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2015-08-03 12:09 -0400 |
| Message-ID | <mpo3k3$ops$1@dont-email.me> |
| In reply to | #66623 |
On 7/31/2015 8:15 PM, David Kleinecke wrote:
> On Thursday, July 30, 2015 at 9:59:20 PM UTC-7, James Kuyper wrote:
>> On 07/30/2015 07:46 PM, David Kleinecke wrote:
>
> You don't comprehend what I mean by documenting so I suggest you stop
> trying to disprove the strawman you set up instead.
>
>>> I assume there is a natural order in expression evaluation.
>>
>> That's a faulty assumption that sheds new light on many of your
>> previously bizarre comments. The sub-expressions of most C expressions
>> have no natural order, which is why the C standard specifies the order
>> only for a few of them.
>
> I don't understand this at all. What, for example, do you mean by
> sub-expression.
>
> Perhaps you mean things like
> a + b + c
> where there are three possible orders of evaluation (all leading to
> the same result by a well known theorem. Nevertheless there is a
> natural order
> (a + b) + c
> You may not have encountered this use of the word "natural" before. It
> means naively obvious.
But why *force* the compiler to use what you say is the "natural" order?
Perhaps it has just calculated c in the previous statement:
c = some_function();
d = a + b + c;
Why force the compiler to ignore the fact that is already holds the value of
c in a register, and prevent it optimizing it to:
d = (c + a) + b;
Or, let's take you "natural order" one step further:
a + b + c + d ==> ( ( a + b ) + c ) + d
Why not let a "hyperthreading" CPU do:
( a + b ) + ( c + d )
where (a+b) and (c+d) are calculated in parallel?
Why encumber the compiler, preventing such optimizations?
> Not everything has a natural representation - finite groups, for example,
> do not. But things like a set of integers do.
>
> Natural does not mean "required". An optimizer can juggle the order
> freely (within the obvious limitation).
In other words, "the order is unspecified"?
> I admit there are other ways of doing the arithmetic. They just aren't
> the natural way. But they may be more efficient.
So let the compiler take the "not natural" but "more efficient" approach.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-03 13:26 -0400 |
| Message-ID | <55BFA42D.9000406@verizon.net> |
| In reply to | #66795 |
On 08/03/2015 12:09 PM, Ken Brody wrote:
> On 7/31/2015 8:15 PM, David Kleinecke wrote:
...
>> Perhaps you mean things like
>> a + b + c
>> where there are three possible orders of evaluation (all leading to
>> the same result by a well known theorem. Nevertheless there is a
>> natural order
>> (a + b) + c
>> You may not have encountered this use of the word "natural" before. It
>> means naively obvious.
>
> But why *force* the compiler to use what you say is the "natural" order?
> Perhaps it has just calculated c in the previous statement:
>
> c = some_function();
> d = a + b + c;
>
> Why force the compiler to ignore the fact that is already holds the value of
> c in a register, and prevent it optimizing it to:
>
> d = (c + a) + b;
The C standard does NOT allow that, except by way of the as-if rule.
(c+a)+b overflows for different values of 'a', 'b' and 'c' than (a+b)+c.
If, on a given platform, overflows are handled in such a way that
(a+b)+c is guaranteed to give the same result as (c+a)+b, then such
rearrangement is allowed by the as-if rule - but only on that platform.
On a platform where overflow causes a signal to be raise()d, such a
rearrangement is not allowed.
> Or, let's take you "natural order" one step further:
>
> a + b + c + d ==> ( ( a + b ) + c ) + d
>
> Why not let a "hyperthreading" CPU do:
>
> ( a + b ) + ( c + d )
>
> where (a+b) and (c+d) are calculated in parallel?
The same issue applies here.
> Why encumber the compiler, preventing such optimizations?
>
>> Not everything has a natural representation - finite groups, for example,
>> do not. But things like a set of integers do.
>>
>> Natural does not mean "required". An optimizer can juggle the order
>> freely (within the obvious limitation).
>
> In other words, "the order is unspecified"?
Not quite: he's made it clear that "the obvious limitation" he's
referring to is that the final result must not be changed. As far as the
C standard is concerned, "the order is unspecified" allows even
optimizations that do change the final result, such as
putc('a')+putc('b'), which can print either "ab" or "ba". If you want
"ba", and don't want "ab", then you don't write code like that.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-03 17:53 -0700 |
| Message-ID | <7bac9a68-ea29-4022-9c6d-eb1f9211e130@googlegroups.com> |
| In reply to | #66806 |
On Monday, August 3, 2015 at 10:26:14 AM UTC-7, James Kuyper wrote:
> On 08/03/2015 12:09 PM, Ken Brody wrote:
> > On 7/31/2015 8:15 PM, David Kleinecke wrote:
> ...
> >> Perhaps you mean things like
> >> a + b + c
> >> where there are three possible orders of evaluation (all leading to
> >> the same result by a well known theorem. Nevertheless there is a
> >> natural order
> >> (a + b) + c
> >> You may not have encountered this use of the word "natural" before. It
> >> means naively obvious.
> >
> > But why *force* the compiler to use what you say is the "natural" order?
> > Perhaps it has just calculated c in the previous statement:
> >
> > c = some_function();
> > d = a + b + c;
> >
> > Why force the compiler to ignore the fact that is already holds the value of
> > c in a register, and prevent it optimizing it to:
> >
> > d = (c + a) + b;
>
> The C standard does NOT allow that, except by way of the as-if rule.
> (c+a)+b overflows for different values of 'a', 'b' and 'c' than (a+b)+c.
> If, on a given platform, overflows are handled in such a way that
> (a+b)+c is guaranteed to give the same result as (c+a)+b, then such
> rearrangement is allowed by the as-if rule - but only on that platform.
> On a platform where overflow causes a signal to be raise()d, such a
> rearrangement is not allowed.
>
> > Or, let's take you "natural order" one step further:
> >
> > a + b + c + d ==> ( ( a + b ) + c ) + d
> >
> > Why not let a "hyperthreading" CPU do:
> >
> > ( a + b ) + ( c + d )
> >
> > where (a+b) and (c+d) are calculated in parallel?
>
> The same issue applies here.
>
> > Why encumber the compiler, preventing such optimizations?
> >
> >> Not everything has a natural representation - finite groups, for example,
> >> do not. But things like a set of integers do.
> >>
> >> Natural does not mean "required". An optimizer can juggle the order
> >> freely (within the obvious limitation).
> >
> > In other words, "the order is unspecified"?
>
> Not quite: he's made it clear that "the obvious limitation" he's
> referring to is that the final result must not be changed. As far as the
> C standard is concerned, "the order is unspecified" allows even
> optimizations that do change the final result, such as
> putc('a')+putc('b'), which can print either "ab" or "ba". If you want
> "ba", and don't want "ab", then you don't write code like that.
putchar('a') + putchar ('b')
Neat. But what does "final result" mean exactly? They both got printed -
in what order is of no concern to the program.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-03 18:44 -0700 |
| Message-ID | <lnd1z3hlou.fsf@kst-u.example.com> |
| In reply to | #66827 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Monday, August 3, 2015 at 10:26:14 AM UTC-7, James Kuyper wrote:
[...]
> putchar('a') + putchar ('b')
>
> Neat. But what does "final result" mean exactly? They both got printed -
> in what order is of no concern to the program.
Haven't you been saying that you want the unspecified order of
evaluation of the two operands of "+" to be implementation-defined?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-04 17:59 -0700 |
| Message-ID | <b09887cc-dc2b-45a1-ae3c-ea1d51c75ab6@googlegroups.com> |
| In reply to | #66836 |
On Monday, August 3, 2015 at 6:34:25 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Monday, August 3, 2015 at 10:26:14 AM UTC-7, James Kuyper wrote:
> [...]
> > putchar('a') + putchar ('b')
> >
> > Neat. But what does "final result" mean exactly? They both got printed -
> > in what order is of no concern to the program.
>
> Haven't you been saying that you want the unspecified order of
> evaluation of the two operands of "+" to be implementation-defined?
>
Is '+' a function? I don't think it is in C (any version).
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-08-05 02:23 +0100 |
| Message-ID | <mproeo$lfp$2@dont-email.me> |
| In reply to | #66894 |
On 05/08/15 01:59, David Kleinecke wrote:
> On Monday, August 3, 2015 at 6:34:25 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > On Monday, August 3, 2015 at 10:26:14 AM UTC-7, James Kuyper wrote:
>> [...]
>> > putchar('a') + putchar ('b')
>> >
>> > Neat. But what does "final result" mean exactly? They both got printed -
>> > in what order is of no concern to the program.
>>
>> Haven't you been saying that you want the unspecified order of
>> evaluation of the two operands of "+" to be implementation-defined?
>>
>
> Is '+' a function?
No, it's an operator, the order of evaluation of whose operands is left
unspecified by the Standard - precisely the kind of behaviour you've
been lobbying to have spelled out. Keith's point is that you appear to
have changed your mind (which is not a criticism - when you're wrong,
changing your mind is a Good Thing).
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-04 21:39 -0400 |
| Message-ID | <mprpdp$fna$1@dont-email.me> |
| In reply to | #66894 |
On 08/04/2015 08:59 PM, David Kleinecke wrote:
> On Monday, August 3, 2015 at 6:34:25 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>>> On Monday, August 3, 2015 at 10:26:14 AM UTC-7, James Kuyper wrote:
>> [...]
>>> putchar('a') + putchar ('b')
>>>
>>> Neat. But what does "final result" mean exactly? They both got printed -
>>> in what order is of no concern to the program.
>>
>> Haven't you been saying that you want the unspecified order of
>> evaluation of the two operands of "+" to be implementation-defined?
>>
>
> Is '+' a function? I don't think it is in C (any version).
The order of evaluation of the operands of an expression is unspecified
for almost all expression types in C, including addition expressions;
it's not just function call expressions. The only exceptions:
A || B
A && B
A ? B : C
A, B
In all four cases, there's a sequence point separating A and B (or C),
which means that the evaluation of A, including it's side-effects (if
any) is sequenced before the evaluation of B (or C) (if it occurs),
including it's side-effects, if any.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-04 19:27 -0700 |
| Message-ID | <lnvbcufp0b.fsf@kst-u.example.com> |
| In reply to | #66894 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Monday, August 3, 2015 at 6:34:25 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > On Monday, August 3, 2015 at 10:26:14 AM UTC-7, James Kuyper wrote:
>> [...]
>> > putchar('a') + putchar ('b')
>> >
>> > Neat. But what does "final result" mean exactly? They both got printed -
>> > in what order is of no concern to the program.
>>
>> Haven't you been saying that you want the unspecified order of
>> evaluation of the two operands of "+" to be implementation-defined?
>>
>
> Is '+' a function? I don't think it is in C (any version).
No, of course not. Why do you ask?
The order of evaluation of the arguments in a function call is
unspecified.
Similarly, the order of evaluation of the operands of the + operator is
unspecified.
My impression is that you want both to be implementation-defined rather
than unspecified. In fact, I think you've said that *all* unspecified
behavior should be implementation-defined. As I recall, I (or perhaps
someone else) chose to focus on function arguments as a concrete
example.
Did I misunderstand you? (It's entirely possible that I did.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-04 00:25 -0400 |
| Message-ID | <mppep8$e2e$1@dont-email.me> |
| In reply to | #66827 |
On 08/03/2015 08:53 PM, David Kleinecke wrote:
> On Monday, August 3, 2015 at 10:26:14 AM UTC-7, James Kuyper wrote:
>> On 08/03/2015 12:09 PM, Ken Brody wrote:
>>> On 7/31/2015 8:15 PM, David Kleinecke wrote:
...
>>>> Natural does not mean "required". An optimizer can juggle the order
>>>> freely (within the obvious limitation).
>>>
>>> In other words, "the order is unspecified"?
>>
>> Not quite: he's made it clear that "the obvious limitation" he's
>> referring to is that the final result must not be changed. As far as the
>> C standard is concerned, "the order is unspecified" allows even
>> optimizations that do change the final result, such as
>> putc('a')+putc('b'), which can print either "ab" or "ba". If you want
>> "ba", and don't want "ab", then you don't write code like that.
>
> putchar('a') + putchar ('b')
You're correct. I almost never use the lowest-level I/O functions; I
should have checked before writing that.
> Neat. But what does "final result" mean exactly? ...
In this context, by "final result" I meant all of the outputs of the
program. That basically means the results of calling the output
functions in <stdio.h>, or the corresponding wide-character functions
declared in other headers. As far as I'm concerned, it should also
include the exits status of the program, but a number of people (some of
them on the committee) have disagreed with me on that point. As far as
the standard is concerned, writes to volatile-qualified objects are also
included, which matters only for certain kinds of programming that I've
never had to be involved with, where that volatile-qualified memory is
shared either with another process, or with an attached device.
> ... They both got printed -
> in what order is of no concern to the program.
That code, as written, as written, implies that the order is of no
concern. If that's the truth, there there's no problem with writing such
code. However, it's far more common for the order to matter, and if so,
such code should be modified to impose the desired order.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Ken Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2015-08-04 11:55 -0400 |
| Message-ID | <mpqn5n$p53$1@dont-email.me> |
| In reply to | #66806 |
On 8/3/2015 1:26 PM, James Kuyper wrote:
> On 08/03/2015 12:09 PM, Ken Brody wrote:
[...]
>> c = some_function();
>> d = a + b + c;
>>
>> Why force the compiler to ignore the fact that is already holds the value of
>> c in a register, and prevent it optimizing it to:
>>
>> d = (c + a) + b;
>
> The C standard does NOT allow that, except by way of the as-if rule.
I thought that was implied.
> (c+a)+b overflows for different values of 'a', 'b' and 'c' than (a+b)+c.
> If, on a given platform, overflows are handled in such a way that
> (a+b)+c is guaranteed to give the same result as (c+a)+b, then such
> rearrangement is allowed by the as-if rule - but only on that platform.
> On a platform where overflow causes a signal to be raise()d, such a
> rearrangement is not allowed.
But, 3.4.3p3 states:
An example of undefined behavior is the behavior on integer overflow.
Must a platform which overflows on (a+b)+c also overflow for a+(b+c), and
vice versa? Doesn't J.1 state:
The order in which subexpressions are evaluated and the order in which
side effects take place, except as specified for the function-call (),
&&, ||, ?:, and comma operators (6.5).
[...]
>>> Natural does not mean "required". An optimizer can juggle the order
>>> freely (within the obvious limitation).
>>
>> In other words, "the order is unspecified"?
>
> Not quite: he's made it clear that "the obvious limitation" he's
> referring to is that the final result must not be changed. As far as the
> C standard is concerned, "the order is unspecified" allows even
> optimizations that do change the final result, such as
> putc('a')+putc('b'), which can print either "ab" or "ba". If you want
> "ba", and don't want "ab", then you don't write code like that.
Well, in math (a+b)+c is always equal to a+(b+c). In C, overflow may occur,
but that introduces UB, which throws out any "expected" result.
Unless the OP is suggesting that overflows must occur exactly as if a+b were
done prior to adding c.
Now, perhaps if he were to be suggesting that the compiler must do
parenthesized subexpressions first, so that an explicit "(a+b)+c" could not
be rearranged to "a+(b+c)", I might go along. (Of course, if "c" itself
were an expression, that could still be calculated prior to "(a+b)".)
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-08-04 10:31 -0700 |
| Message-ID | <MPG.302a96cf8c81a99c4c@news.eternal-september.org> |
| In reply to | #66867 |
Ken Brody wrote:
>
> On 8/3/2015 1:26 PM, James Kuyper wrote:
> > On 08/03/2015 12:09 PM, Ken Brody wrote:
> [...]
> >> c = some_function();
> >> d = a + b + c;
> >>
> >> Why force the compiler to ignore the fact that is already holds the value of
> >> c in a register, and prevent it optimizing it to:
> >>
> >> d = (c + a) + b;
> >
> > The C standard does NOT allow that, except by way of the as-if rule.
>
> I thought that was implied.
>
> > (c+a)+b overflows for different values of 'a', 'b' and 'c' than (a+b)+c.
> > If, on a given platform, overflows are handled in such a way that
> > (a+b)+c is guaranteed to give the same result as (c+a)+b, then such
> > rearrangement is allowed by the as-if rule - but only on that platform.
> > On a platform where overflow causes a signal to be raise()d, such a
> > rearrangement is not allowed.
>
> But, 3.4.3p3 states:
>
> An example of undefined behavior is the behavior on integer overflow.
>
> Must a platform which overflows on (a+b)+c also overflow for a+(b+c), and
> vice versa? Doesn't J.1 state:
>
> The order in which subexpressions are evaluated and the order in which
> side effects take place, except as specified for the function-call (),
> &&, ||, ?:, and comma operators (6.5).
>
> [...]
> >>> Natural does not mean "required". An optimizer can juggle the order
> >>> freely (within the obvious limitation).
> >>
> >> In other words, "the order is unspecified"?
> >
> > Not quite: he's made it clear that "the obvious limitation" he's
> > referring to is that the final result must not be changed. As far as the
> > C standard is concerned, "the order is unspecified" allows even
> > optimizations that do change the final result, such as
> > putc('a')+putc('b'), which can print either "ab" or "ba". If you want
> > "ba", and don't want "ab", then you don't write code like that.
>
> Well, in math (a+b)+c is always equal to a+(b+c). In C, overflow may occur,
> but that introduces UB, which throws out any "expected" result.
>
> Unless the OP is suggesting that overflows must occur exactly as if a+b were
> done prior to adding c.
>
> Now, perhaps if he were to be suggesting that the compiler must do
> parenthesized subexpressions first, so that an explicit "(a+b)+c" could not
> be rearranged to "a+(b+c)", I might go along. (Of course, if "c" itself
> were an expression, that could still be calculated prior to "(a+b)".)
In C, a + b + c is the same as (a + b) + c. The explicit parentheses
don't make any difference in integer operations. If b + c overflows, but
a + b does not and (a + b) + c does not, then the compiler may not
change the order of the additions, unless it knows that the result on
overflow is the same as the correct result.
Note the distinction between the order of evaluation of subexpressions
and the order of operations. I think perhaps some here have been
confusing them. It is perfectly okay to evaluate c before a or b, even
though a+b must be evaluated before the addition of c. (Again, the
compiler can do whatever it wants, as long as it yields the same result
as doing it in the specified way.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-04 13:32 -0400 |
| Message-ID | <mpqsrh$fn7$1@dont-email.me> |
| In reply to | #66867 |
On 08/04/2015 11:55 AM, Ken Brody wrote:
> On 8/3/2015 1:26 PM, James Kuyper wrote:
>> On 08/03/2015 12:09 PM, Ken Brody wrote:
> [...]
>>> c = some_function();
>>> d = a + b + c;
>>>
>>> Why force the compiler to ignore the fact that is already holds the value of
>>> c in a register, and prevent it optimizing it to:
>>>
>>> d = (c + a) + b;
>>
>> The C standard does NOT allow that, except by way of the as-if rule.
>
> I thought that was implied.
>
>> (c+a)+b overflows for different values of 'a', 'b' and 'c' than (a+b)+c.
>> If, on a given platform, overflows are handled in such a way that
>> (a+b)+c is guaranteed to give the same result as (c+a)+b, then such
>> rearrangement is allowed by the as-if rule - but only on that platform.
>> On a platform where overflow causes a signal to be raise()d, such a
>> rearrangement is not allowed.
>
> But, 3.4.3p3 states:
>
> An example of undefined behavior is the behavior on integer overflow.
Yes, and if I've carefully chose the order of a, b, and c, such that a +
b and (a+b)+c will never overflow for the relevant values, even though
(c+a) would overflow, then the behavior should be well defined if I
write a+b+c. I will be correspondingly upset if the optimizer
incorrectly rearranges it as (c+a)+b.
> Must a platform which overflows on (a+b)+c also overflow for a+(b+c), and
> vice versa? Doesn't J.1 state:
>
> The order in which subexpressions are evaluated and the order in which
> side effects take place, except as specified for the function-call (),
> &&, ||, ?:, and comma operators (6.5).
Yes, and that has nothing to do with this. The parse tree for a+b+c is
(a+b)+c. 6.5 says that a and b can be evaluated in any order. It also
says that the order of evaluation of 'c' is unsequenced relative to the
other two, and also to the evaluation of (a+b). However, 6.5 does not
give the implementation permission to add c and a before adding in C.
That is not a permitted way of parsing a+b+c, an issue that is
independent of the evaluation order.
>
> [...]
>>>> Natural does not mean "required". An optimizer can juggle the order
>>>> freely (within the obvious limitation).
>>>
>>> In other words, "the order is unspecified"?
>>
>> Not quite: he's made it clear that "the obvious limitation" he's
>> referring to is that the final result must not be changed. As far as the
>> C standard is concerned, "the order is unspecified" allows even
>> optimizations that do change the final result, such as
>> putc('a')+putc('b'), which can print either "ab" or "ba". If you want
>> "ba", and don't want "ab", then you don't write code like that.
>
> Well, in math (a+b)+c is always equal to a+(b+c). In C, overflow may occur,
> but that introduces UB, which throws out any "expected" result.
Overflow may be avoided, by relying upon that part of the evaluation
sequence which is mandated by C: it mandates that a be added only to b,
and that the result be added to c. If that is sufficient to avoid
overflow, a rearrangement that does not avoid overflow is non-conforming.
> Unless the OP is suggesting that overflows must occur exactly as if a+b were
> done prior to adding c.
I gather that when using 2's complement, that is, in fact, a natural
result - which would probably explain a lack of awareness of this issue
when integer addition and subtraction are involved. Using floating
point, pointers or anything more complicated than addition and
subtraction, and the issue even applies when using 2's complement math.
> Now, perhaps if he were to be suggesting that the compiler must do
> parenthesized subexpressions first, so that an explicit "(a+b)+c" could not
> be rearranged to "a+(b+c)", I might go along. (Of course, if "c" itself
> were an expression, that could still be calculated prior to "(a+b)".)
The C standard mandates that a+b+c be parsed only as the equivalent of
(a+b)+c. Review the grammar for the addition operator, and read the
corresponding semantics.
I've got doctor's appointment to attend, or I'd expand on that comment
in more detail.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-04 22:46 -0400 |
| Message-ID | <mprtaj$23m$1@dont-email.me> |
| In reply to | #66873 |
On 08/04/2015 01:32 PM, James Kuyper wrote:
...
> The C standard mandates that a+b+c be parsed only as the equivalent of
> (a+b)+c. Review the grammar for the addition operator, and read the
> corresponding semantics.
>
> I've got doctor's appointment to attend, or I'd expand on that comment
> in more detail.
Here are those details:
The key point is that 6.5p3 has two sentences:
"The grouping of operators and operands is indicated by the syntax.
Except as specified later, side effects and value computations of
subexpressions are unsequenced."
What you're talking about when you change a+b+c into (c+a)+b, you're
grouping c with a, while the syntax only permits a to be grouped with b.
Such rearrangements are permitted by ordinary math - but computer math
is different. The grouping affects overflow and underflow, and for
floating point expressions it can also determine whether unnecessary
loss of precision occurs. It is therefore essential that the developer
have good control over the grouping. The C standard mandates the
grouping, and allows the developer to specify other possible groupings
by inserting parentheses.
The sequence of side-effects and value computations is something quite
different. It's affected by the grouping: sub-expressions are sequenced
before the expression that they are part of, and there are four specific
operators (||, &&, ?: and the comma operator) that impose additional
sequence requirements. However, that's far from sufficient, in most
cases, to uniquely determine the sequence of side effects and value
computations.
Section (6.5.6p1) specifies the following syntax rules:
additive-expression:
multiplicative-expression
additive-expression + multiplicative-expression
additive-expression - multiplicative-expression
Only the left operand of a additive-expression may be another additive
expression; the right operand must be a multiplicative-expression. It is
this fact that determines how a sequence of additions and subtractions
is grouped. a, b, and c are all parsed as primary-expresions. The C
grammar is structured so that an unadorned expression of one type
qualifies as an expression of the next type in the hierarchy. Therefore,
'a', 'b', and 'c' also qualify as postfix-expressions (6.5.2p1),
unary-expressions (6.5.3p1), cast-expressions(6.5.4p1),
multiplicative-expressions(6.5.5p1), and additive expressions.
However, 'a+b' or 'b+c' qualify only as additive-expressions, not as
multiplicative expressions - they can qualify only as an
additive-expression. The key difference that parentheses make is that
(b+c) is a primary expression, and therefore CAN be parsed as a
multiplicative expression.
Treating 'b+c' as an additive expression in this context would therefore
be inconsistent with the grammar. 'a+b+c' must be parsed as 'a+b' being
an additive expression which is the left operand of the second additive
expression, with 'c' as the corresponding right operand. The semantics
for additive-expressions involving arithmetic types is that "The result
of the binary + operator is the sum of the operands." (6.5.6p5). Thus,
a+b+c necessarily calls for adding a and b, and adding the result of
that addition to c. The standard gives no permission to rearrange the
grouping so that c can be added directly to a; it only permits
rearrangement of the timing of the sub-expressions and their side-effects.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Ken Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2015-08-10 12:16 -0400 |
| Message-ID | <mqailo$m4a$1@dont-email.me> |
| In reply to | #66867 |
On 8/4/2015 11:55 AM, Ken Brody wrote: > On 8/3/2015 1:26 PM, James Kuyper wrote: >> On 08/03/2015 12:09 PM, Ken Brody wrote: > [...] >>> c = some_function(); >>> d = a + b + c; >>> >>> Why force the compiler to ignore the fact that is already holds the value of >>> c in a register, and prevent it optimizing it to: >>> >>> d = (c + a) + b; >> >> The C standard does NOT allow that, except by way of the as-if rule. > > I thought that was implied. > >> (c+a)+b overflows for different values of 'a', 'b' and 'c' than (a+b)+c. >> If, on a given platform, overflows are handled in such a way that >> (a+b)+c is guaranteed to give the same result as (c+a)+b, then such >> rearrangement is allowed by the as-if rule - but only on that platform. >> On a platform where overflow causes a signal to be raise()d, such a >> rearrangement is not allowed. [...] Thank you for all the replies. Basically, it comes down to, given "a+b+c", although "a", "b", and "c" can be evaluated in any order, the addition of "a" and "b" must take place prior to adding "c", unless any possible overflow conditions resulting from doing the additions in a different order can be guaranteed to result in the same value. Is that correct? -- Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-10 13:26 -0400 |
| Message-ID | <55C8DEBE.5040001@verizon.net> |
| In reply to | #67073 |
On 08/10/2015 12:16 PM, Ken Brody wrote: ... > Basically, it comes down to, given "a+b+c", although "a", "b", and "c" can > be evaluated in any order, the addition of "a" and "b" must take place prior > to adding "c", unless any possible overflow conditions resulting from doing > the additions in a different order can be guaranteed to result in the same > value. > > Is that correct? Basically, yes, assuming that the promoted types of a, b, and c are all integer types with the same range. If any two of them have different promoted types, then you also need to check whether the implicit type conversions interact with the additions in a way that interferes with the rearrangement. If any of them have floating point type, you also have to worry about loss of precision, and not just overflow.
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web