Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #64878 > unrolled thread

Unspecified behavior in C

Back to article view | Back to comp.lang.c

Contents

  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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

#65922

David Kleinecke <dkleinecke@gmail.com> wrote:

> As to the third point - I will answer with an anecdote. Once
> upon a time I was evaluating nuclear weapon effects codes. I
> hope I don't need to prove that nuclear effects code is an
> important application. I observed that one of the programs was
> using a subroutine to compute air pressures in shock waves and
> the subroutine was giving answers that were, because of a faulty
> unit conversion, about ten times larger than they should be. I
> called the users of this code and pointed out the problem. They
> thanked me said they were going to change nothing because "We're 
> good with what we've got already - it works just fine."

OK - I'm officially calling bullshit on this one.

Richard

[toc] | [prev] | [next] | [standalone]

#65923

On 19/07/15 21:59, Richard Bos wrote:
> David Kleinecke <dkleinecke@gmail.com> wrote:
>
>> As to the third point - I will answer with an anecdote. Once
>> upon a time I was evaluating nuclear weapon effects codes. I
>> hope I don't need to prove that nuclear effects code is an
>> important application. I observed that one of the programs was
>> using a subroutine to compute air pressures in shock waves and
>> the subroutine was giving answers that were, because of a faulty
>> unit conversion, about ten times larger than they should be. I
>> called the users of this code and pointed out the problem. They
>> thanked me said they were going to change nothing because "We're
>> good with what we've got already - it works just fine."
>
> OK - I'm officially calling bullshit on this one.

Then you'd better form an orderly queue.

-- 
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]

#65744

On 07/16/2015 12:19 AM, David Kleinecke wrote:
> On Tuesday, July 14, 2015 at 11:57:50 AM UTC-7, James Kuyper wrote:
...
>> Let's put it this way: I insist that you provide full documentation of
>> how you spent the past week. More documentation is always better, right?
>> So you should have no objection to providing it - but of course, I'm
>> pretty sure that you would object. Even if nothing happened last week
>> that you would consider private, I'm sure you'd at least object to doing
>> the work required to put that documentation together - if you don't have
>> anything better to do with your time, you must be pretty bored.
>>
>> What kind of argument would your want me to give you, in order to
>> convince you to produce such documentation? There certainly are
>> arguments that I could present you to justify such a request (for
>> instance, you could be a suspect in a criminal investigation, and I
>> could be a policeman with relevant jurisdiction). After thinking about
>> that for awhile, maybe you'll have a better idea how to present an
>> argument why the things the standard says are unspecified should be
>> documented.
> 
> This is a tempest in a teapot. 
> 
> I believe that the purpose of the kind of documentation I believe is
> needed is to describe what one can expect a machine (in the abstract
> sense - a comiler to be exact) to do. Your attempt to compare that with
> a what I would call a log of events is laughable.
...

My previous response was written at 01:37 after a long night dealing
with babies who wouldn't stop crying. Now that I look back, I see
precisely what you're referring to. I apologize for my earlier blindness.

I'm curious - what feature of that comparison makes you laugh? Is it the
complete lack of any reason why you should give me that "log of events"?
That was the whole point of the analogy - you've given us no reason
other than your own personal preference, why anyone should provide the
documentation you've requested, and it's documentation that doesn't seem
to have any useful purpose.

Is your laughter targeted as some other feature of this "log of events"
than it's lack of justification? Then in that case, please reconsider my
analogy, replacing "Full documentation of how you spent the last week"
with any other request that fails to elicit laughter on your part, but
is also completely lacking in any obvious justification why you should
comply with the request.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#65751

On 07/16/2015 12:19 AM, David Kleinecke wrote:
...
> And I have repeatedly said my reason is that I want everything
> documented and you wont accept that as a reason. You have not
> stated any clearer opposition to that principle other than that
> it is too much trouble.

Well, it is a lot of trouble, and that is, in the absence of a
sufficiently strong reason to do something, a perfectly legitimate
reason for not doing it. That's why we've repeatedly asked you to
provide that strong reason. "I want it" isn't strong enough, not when
"I" is just one person, and the people who would need to go to the
trouble of writing and reading unnecessary documentation number at least
in the thousands.

However, we have given you other reasons. Since you didn't recognize
them as such, I won't feel I'm wasting my time by repeating down below
some of the things I've said earlier in this thread.

...
> If we want a clear debate let us try this:
> 
>    Resolved a C compiler shall document what is does to a source
>    program in every detail including cases where more than one
>    outcome is possible. 
> 
> I visualize myself as FOR and you as AGAINST.
> 
> Now it is your turn.

As the person proposing this change, it's your responsibility to go
first with your arguments for this proposal. However, since you've not
seen fit to do so, I can start.

"every detail" is more detail than users have any need for. Requiring
that every detail be documented would have several effects: it would
make it excessively difficult to write the documentation, excessively
difficult to keep the documentation up-to-date, and excessively
difficult for users to search the document for what they need. People
can reasonably be expected to react by trying to avoid having to do that
work, either by avoiding implementing any sophisticated optimization
that are hard to describe, or by failing to provide the required
documentation, rendering their implementation non-conforming.

Let me get more specific, by concentrating on the following items the
list of unspecified behavior in Annex J of the current standard:

> — The order in which the function designator, arguments, and subexpressions within the
> arguments are evaluated in a function call (6.5.2.2).
...
> — The order in which the operands of an assignment operator are evaluated (6.5.16).

The current standard doesn't explicitly say that the order is
unspecified. Rather, 6.5.2.2p10 says "There is a sequence point after
the evaluations of the function designator and the actual
arguments but before the actual call.", and 6.5.16p3 says "The
evaluations of the operands are unsequenced." In the absence of any
other sequence points, those statements have the same effect as saying
that the order is unspecified..

Lets consider the following code:

	int *desired_object();
	int (*desired_function)(int, int);
	int first();
	int second();

	*desired_object() = (*desired_function())(first(),second());

With the C standard as currently written, it's not specified which order
desired_object(), desired_function(), first() and second() are called
in. The only requirements imposed on the order is that
(*desired_function())() must not be called until after
desired_function(), first(), and second() have all been called, and that
*desired_object() cannot change value until all of the functions have
been called.

This freedom allows the implementation to choose to execute the
functions in whichever order is fastest (or otherwise most convenient).
But there's a corresponding problem: what it the functions have
side-effects, and it's important that those side-effects occur in a
particular order? In particular, lets assume that they need to occur in
the following order: desired_object(), desired_function(), first(),
second(). That's trivial to deal with:

	int *int_ptr = desired_object();
	int (*func_ptr)(int, int) = desired_function();
	int left = first();

	*int_ptr = (*func_ptr)(left, second());

Now, if your proposal were approved, an implementation would have to
document exactly how it decides what order those functions get called
in. With aggressive optimization, that description could be, in itself,
the size of a small book - with a correspondingly low chance of it being
exactly correct, and also a very low chance of it being understood
perfectly.
This would give implementors an incentive to avoid aggressive
optimizations that are too hard to explain, and also an incentive to not
bother documenting it at all, even though that will mean that they can't
claim to be fully conforming.
Can you suggest any benefit from mandating such documentation that would
make up for these costs?
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#65821

On Thursday, July 16, 2015 at 8:09:31 PM UTC-7, James Kuyper wrote:
> On 07/16/2015 12:19 AM, David Kleinecke wrote:
> ...
> > And I have repeatedly said my reason is that I want everything
> > documented and you wont accept that as a reason. You have not
> > stated any clearer opposition to that principle other than that
> > it is too much trouble.
> 
> Well, it is a lot of trouble, and that is, in the absence of a
> sufficiently strong reason to do something, a perfectly legitimate
> reason for not doing it. That's why we've repeatedly asked you to
> provide that strong reason. "I want it" isn't strong enough, not when
> "I" is just one person, and the people who would need to go to the
> trouble of writing and reading unnecessary documentation number at least
> in the thousands.
> 
> However, we have given you other reasons. Since you didn't recognize
> them as such, I won't feel I'm wasting my time by repeating down below
> some of the things I've said earlier in this thread.
> 
> ...
> > If we want a clear debate let us try this:
> > 
> >    Resolved a C compiler shall document what is does to a source
> >    program in every detail including cases where more than one
> >    outcome is possible. 
> > 
> > I visualize myself as FOR and you as AGAINST.
> > 
> > Now it is your turn.
> 
> As the person proposing this change, it's your responsibility to go
> first with your arguments for this proposal. However, since you've not
> seen fit to do so, I can start.
> 
> "every detail" is more detail than users have any need for. Requiring
> that every detail be documented would have several effects: it would
> make it excessively difficult to write the documentation, excessively
> difficult to keep the documentation up-to-date, and excessively
> difficult for users to search the document for what they need. People
> can reasonably be expected to react by trying to avoid having to do that
> work, either by avoiding implementing any sophisticated optimization
> that are hard to describe, or by failing to provide the required
> documentation, rendering their implementation non-conforming.
> 
> Let me get more specific, by concentrating on the following items the
> list of unspecified behavior in Annex J of the current standard:
> 
> > -- The order in which the function designator, arguments, and subexpressions within the
> > arguments are evaluated in a function call (6.5.2.2).
> ...
> > -- The order in which the operands of an assignment operator are evaluated (6.5.16).
> 
> The current standard doesn't explicitly say that the order is
> unspecified. Rather, 6.5.2.2p10 says "There is a sequence point after
> the evaluations of the function designator and the actual
> arguments but before the actual call.", and 6.5.16p3 says "The
> evaluations of the operands are unsequenced." In the absence of any
> other sequence points, those statements have the same effect as saying
> that the order is unspecified..
> 
> Lets consider the following code:
> 
> 	int *desired_object();
> 	int (*desired_function)(int, int);
> 	int first();
> 	int second();
> 
> 	*desired_object() = (*desired_function())(first(),second());
> 
> With the C standard as currently written, it's not specified which order
> desired_object(), desired_function(), first() and second() are called
> in. The only requirements imposed on the order is that
> (*desired_function())() must not be called until after
> desired_function(), first(), and second() have all been called, and that
> *desired_object() cannot change value until all of the functions have
> been called.
> 
> This freedom allows the implementation to choose to execute the
> functions in whichever order is fastest (or otherwise most convenient).
> But there's a corresponding problem: what it the functions have
> side-effects, and it's important that those side-effects occur in a
> particular order? In particular, lets assume that they need to occur in
> the following order: desired_object(), desired_function(), first(),
> second(). That's trivial to deal with:
> 
> 	int *int_ptr = desired_object();
> 	int (*func_ptr)(int, int) = desired_function();
> 	int left = first();
> 
> 	*int_ptr = (*func_ptr)(left, second());
> 
> Now, if your proposal were approved, an implementation would have to
> document exactly how it decides what order those functions get called
> in. With aggressive optimization, that description could be, in itself,
> the size of a small book - with a correspondingly low chance of it being
> exactly correct, and also a very low chance of it being understood
> perfectly.
> This would give implementors an incentive to avoid aggressive
> optimizations that are too hard to explain, and also an incentive to not
> bother documenting it at all, even though that will mean that they can't
> claim to be fully conforming.
> Can you suggest any benefit from mandating such documentation that would
> make up for these costs?
 
I don't think any of you have ever done a cost-benfit analysis. Google
"cost-benefit" for more references than you want. 

In the absence of any way to resolve this dilemma we much fall back
on subjective, That is where I started.  

[toc] | [prev] | [next] | [standalone]

#65825

On 07/17/2015 09:48 PM, David Kleinecke wrote:
...
> I don't think any of you have ever done a cost-benfit analysis. Google
> "cost-benefit" for more references than you want. 

A proper cost-benefit analysis requires precise numbers for comparison.
In this context, precise numbers are difficult or even to obtain. Even
imprecise numbers are hard to obtain. The best that can be done is a
purely qualitative discussion: description of the costs and benefits,
without quantification. That's all we've ever asked you to do: describe,
at least qualitatively, what the benefits are of mandating documentation
of these details. Your absolute and complete refusal to describe any
such benefits provides support for our pre-existing belief, based upon a
great deal of experience with such matters, that such a change would
have no benefits. That makes the cost-benefit analysis very easy:
costs=substantial, though hard to quantify; benefits=none, and therefore
easy to quantify: 0.

Note that this not just the belief of me and the other people who are
discussing this subject with you; the fact that the standard says that
these things are unspecified implies that a solid majority (and more
likely a super-majority) of the committee feels the same way. The
committee is not ignorant of any issue you've raised in this discussion
- they just disagree with you about the importance and relevance of
those issues.

> In the absence of any way to resolve this dilemma we much fall back
> on subjective, That is where I started.

What dilemma are we facing? We have costs that we cannot quantify,
beyond saying that they are substantial, but can describe; and benefits
that we consider non-existent, and which you refuse to describe. That's
not a dilemma, it's a very easy decision to make.

When costs and benefits are hard to quantify, everyone is going to have
to use their own subjective impressions to decide whether the costs are
higher than the benefits. Because of the subjectivity of that
evaluation, should you ever choose to identify the benefits of
documenting this information, we might disagree with you strongly about
those subjective evaluations. But before we can even get to the point of
performing those evaluations, you're first going to have to describe
those benefits.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#65921

David Kleinecke <dkleinecke@gmail.com> wrote:

> On Tuesday, July 14, 2015 at 11:57:50 AM UTC-7, James Kuyper wrote:
> > On 07/14/2015 12:29 PM, James Kuyper wrote:
> > > On 07/14/2015 12:16 PM, David Kleinecke wrote:
> > > ...
> > >> OK. I admit that it never occurred to me that anyone would object
> > >> to better documentation as a goal.
> > > 
> > > We don't. We object to making documentation worse by including in it
> > > things that don't need to be documented, and which might make the
> > > documentation unreadably complicated and unacceptably difficult to create.
> > 
> > Note, in particular, that we're willing to consider the possibility that
> > we're wrong about any particular items not needing to be documented.
> > We're willing to listen to your explanation why documenting these things
> > would make the documentation better (as opposed to merely bigger). I
> > can't guarantee that we'll agree when we've heard your reasons - but
> > we'll never have even a chance of learning that we were wrong unless you
> > articulate your reasons - and we've repeatedly requested that you give
> > us that chance.
> 
> And I have repeatedly said my reason is that I want everything 
> documented and you wont accept that as a reason.

But _WHY!!!!_ do you want everything documented? For the love of all
that's pentatentacular and Yuggoth-like, _WHY!!!!???_ Just "I want it"
_IS NOT A REASON_!

> You have not stated any clearer opposition to that principle other
> than that it is too much trouble.  

We have collectively stated several more reasons than that, including:

- it is _unnecessary_ trouble for someone who is already managing a
  pretty big project;
- it may not even be realistically possible;
- in many cases, the documentation will boil down to "you can't know
  this without running the compiler, which is what you were going to
  do in the first place";
- it will lead you (not me, but judging by your posts almost certainly
  you) into premature optimisation and unwarranted assumptions about
  what is and isn't portable - or even correct.

Those are four good reasons. You have given exactly _NONE_, except for
the non-reason "I want it that way". If you want to convince anyone,
you're going to have to come up with arguments, not demands.

> You don't seem to recognize a reason when you see one. 

Excuse me. Pot, meet kettle. The kettle is nice and clean, you're full
of caked-up porridge.

> This is a tempest in a teapot. 

You're the main blower.

> If we want a clear debate let us try this:
> 
>    Resolved

No. This is not a sophomoric game, this is our _job_. Not yours,
evidently - you're clearly merely in academe - but most of ours, and a
real job at that.

Richard

[toc] | [prev] | [next] | [standalone]

#65925

On 07/19/2015 04:57 PM, Richard Bos wrote:
> David Kleinecke <dkleinecke@gmail.com> wrote:
...
> No. This is not a sophomoric game, this is our _job_. Not yours,
> evidently - you're clearly merely in academe - but most of ours, and a
> real job at that.

I must have missed that. What has he revealed about his academic
background? I admit that his insistence that "every detail be
documented" has a ivory-tower tinge to it, but I've met people who'd
long since left academia who made similarly ridiculous assertions.

[toc] | [prev] | [next] | [standalone]

#65947

On Sunday, July 19, 2015 at 2:22:22 PM UTC-7, James Kuyper wrote:
> On 07/19/2015 04:57 PM, Richard Bos wrote:
> > David Kleinecke <dkleinecke@gmail.com> wrote:
> ...
> > No. This is not a sophomoric game, this is our _job_. Not yours,
> > evidently - you're clearly merely in academe - but most of ours, and a
> > real job at that.
> 
> I must have missed that. What has he revealed about his academic
> background? I admit that his insistence that "every detail be
> documented" has a ivory-tower tinge to it, but I've met people who'd
> long since left academia who made similarly ridiculous assertions.

You can find out a lot about me by googling me. Only a few other David
Kleineckes.

[toc] | [prev] | [next] | [standalone]

#65948

On 07/19/2015 09:57 PM, David Kleinecke wrote:
> On Sunday, July 19, 2015 at 2:22:22 PM UTC-7, James Kuyper wrote:
>> On 07/19/2015 04:57 PM, Richard Bos wrote:
>>> David Kleinecke <dkleinecke@gmail.com> wrote:
>> ...
>>> No. This is not a sophomoric game, this is our _job_. Not yours,
>>> evidently - you're clearly merely in academe - but most of ours, and a
>>> real job at that.
>>
>> I must have missed that. What has he revealed about his academic
>> background? I admit that his insistence that "every detail be
>> documented" has a ivory-tower tinge to it, but I've met people who'd
>> long since left academia who made similarly ridiculous assertions.
> 
> You can find out a lot about me by googling me. Only a few other David
> Kleineckes.

A quick Google search found about a half dozen of them, a couple of
which had computer programming backgrounds, I didn't find anything that
hinted that any of them were academics. Therefore, I doubt Richard Bos
reached that conclusion based upon a google search like the one I did.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#65950

On Sunday, July 19, 2015 at 7:16:16 PM UTC-7, James Kuyper wrote:
> On 07/19/2015 09:57 PM, David Kleinecke wrote:
> > On Sunday, July 19, 2015 at 2:22:22 PM UTC-7, James Kuyper wrote:
> >> On 07/19/2015 04:57 PM, Richard Bos wrote:
> >>> David Kleinecke <dkleinecke@gmail.com> wrote:
> >> ...
> >>> No. This is not a sophomoric game, this is our _job_. Not yours,
> >>> evidently - you're clearly merely in academe - but most of ours, and a
> >>> real job at that.
> >>
> >> I must have missed that. What has he revealed about his academic
> >> background? I admit that his insistence that "every detail be
> >> documented" has a ivory-tower tinge to it, but I've met people who'd
> >> long since left academia who made similarly ridiculous assertions.
> > 
> > You can find out a lot about me by googling me. Only a few other David
> > Kleineckes.
> 
> A quick Google search found about a half dozen of them, a couple of
> which had computer programming backgrounds, I didn't find anything that
> hinted that any of them were academics. Therefore, I doubt Richard Bos
> reached that conclusion based upon a google search like the one I did.
> -- 

I thought you meant my academicc type achievements - not my career. I was
on the faculty of UC Berkeley for one year around 1955. I was an Instructor
in Mathematics. I think Instructor no longer exists as title but in those
days it ranked lower than Assistant Professor. Much later, also at 
Berkeley, I was an Associate Research Engineer. for a couple of years. I 
think that covers my academic career.

[toc] | [prev] | [next] | [standalone]

#66585

On Wednesday, July 15, 2015 at 11:19:24 PM UTC-5, David Kleinecke wrote:
> On Tuesday, July 14, 2015 at 11:57:50 AM UTC-7, James Kuyper wrote:
> > On 07/14/2015 12:29 PM, James Kuyper wrote:
> > > On 07/14/2015 12:16 PM, David Kleinecke wrote:
> > > ...
> > >> OK. I admit that it never occurred to me that anyone would object
> > >> to better documentation as a goal.
> > > 
> > > We don't. We object to making documentation worse by including in it
> > > things that don't need to be documented, and which might make the
> > > documentation unreadably complicated and unacceptably difficult to create.
> > 
> > Note, in particular, that we're willing to consider the possibility that
> > we're wrong about any particular items not needing to be documented.
> > We're willing to listen to your explanation why documenting these things
> > would make the documentation better (as opposed to merely bigger). I
> > can't guarantee that we'll agree when we've heard your reasons - but
> > we'll never have even a chance of learning that we were wrong unless you
> > articulate your reasons - and we've repeatedly requested that you give
> > us that chance.
> 
> And I have repeatedly said my reason is that I want everything 
> documented and you wont accept that as a reason. You have not
> stated any clearer opposition to that principle other than that 
> it is too much trouble.  
>  

> > Realistically, the fact that you've repeatedly refused the request, the
> > fact that you don't even seem to understand the request, creates the
> > strong suspicion that you are incapable of articulating a reason. 
> 
> You don't seem to recognize a reason when you see one. 

"I want it" is not a *good* reason.

"I am writing code where knowing the order in which static objects are
initialized allows me to gain performance" is a decent reason.

> 
> > If you could, you would probably already have done so. You seem so firmly
> > convinced that no justification is needed for any documentation, that
> > you've probably never even thought about what a proper argument
> > justifying such a requirement would look like. Nonetheless, should you
> > ever manage to come up with such an argument, I encourage you to present
> > it. We'll probably find it full of holes, but I think that all of us
> > will learn something from the process.
> > 
> > Let's put it this way: I insist that you provide full documentation of
> > how you spent the past week. More documentation is always better, right?
> > So you should have no objection to providing it - but of course, I'm
> > pretty sure that you would object. Even if nothing happened last week
> > that you would consider private, I'm sure you'd at least object to doing
> > the work required to put that documentation together - if you don't have
> > anything better to do with your time, you must be pretty bored.
> > 
> > What kind of argument would your want me to give you, in order to
> > convince you to produce such documentation? There certainly are
> > arguments that I could present you to justify such a request (for
> > instance, you could be a suspect in a criminal investigation, and I
> > could be a policeman with relevant jurisdiction). After thinking about
> > that for awhile, maybe you'll have a better idea how to present an
> > argument why the things the standard says are unspecified should be
> > documented.
> 
> This is a tempest in a teapot. 
> 
> I believe that the purpose of the kind of documentation I believe is
> needed is to describe what one can expect a machine (in the abstract
> sense - a comiler to be exact) to do. Your attempt to compare that with
> a what I would call a log of events is laughable.
> 
> If we want a clear debate let us try this:
> 
>    Resolved a C compiler shall document what is does to a source
>    program in every detail including cases where more than one
>    outcome is possible. 
> 
> I visualize myself as FOR and you as AGAINST.
> 
> Now it is your turn.

So, let's talk about order of evaluation.

Assume the statement:

    a = b + c * d;

The order in which b, c, and d are evaluated is unspecified.  Let's consider
things which might influence evaluation order.  

Suppose the prior statement is

    b = d - 1;

b and d have *already been evaluated*; assuming a modern processor with
multiple general purpose data registers, those values will already be
available, so the only thing that *really* needs to be evaluated is in
the current statement is c.

However, if the prior statement is

    c = 5;

then c has already been evaluated, so both b and d need to be evaluated for
the current statement.

So order of evaluation may depend on prior statements and evaluations.  Of
course, since you want this documented "in every detail", you'd have to
consider all possible permutations of prior statements.  

Then there's the instruction set to consider; on x86, it makes more sense
to do the multiplication followed by the add, so it makes sense to evaluate
c and d before b.  That may not be true on other architectures. 

So order of evaluation may depend on the instruction set.  Since some 
compilers like gcc have been ported to different architectures, they'd
have to list all possible permutations of evaluation order based on 
the architecture, in addition to all possible permutations of prior 
statements above.  

Note that we haven't even discussed side effects: imagine a statement
like

    a = b++ + --c * d++;

that could also play a role in determining evaluation order.  

Now imagine that b, c, and d are different arithmetic types (int, float,
double, etc.).  That's another thing that could potentially affect
evaluation order.  

Documenting all possible permutations of evaluation order based on 
instruction sets, prior code, and other factors would be a *massive*
pain in the ass.  When faced with that kind of a documentation burden, 
I expect most implementors would simply say, "screw it, we'll do it the 
Java/C# way, optimization be damned". 

And, assuming you actually *read* that documentation, is that going to
affect how you write your code?  Are you going to try to micro-optimize 
for a particular platform, at the expense of portability? 

I asked this before: have you run into a situation where the performance
or correctness of your code suffered because you didn't know the *exact*
behavior picked by the implementation?  If you have, then demanding some
level of documentation may be reasonable.  Otherwise, you just want a po

[toc] | [prev] | [next] | [standalone]

#66586

John Bode <jfbode1029@gmail.com> writes:
[...]
> So, let's talk about order of evaluation.
>
> Assume the statement:
>
>     a = b + c * d;
>
> The order in which b, c, and d are evaluated is unspecified.  Let's consider
> things which might influence evaluation order.  
[...]
> Then there's the instruction set to consider; on x86, it makes more sense
> to do the multiplication followed by the add, so it makes sense to evaluate
> c and d before b.  That may not be true on other architectures. 
[...]

The addition *cannot* be performed until the result of the
multiplication is known.  b, c, and d (which may be complex
subexpressions) can be evaluated any any of the 6 possible orders, but
the evaluations of c and d must precede the multiplication, and the
multiplication and evaluation of b must precede the addition.

C11 is more explicit about this than previous editions of the standard.
N1570 6.5p1:

    The value computations of the operands of an operator are sequenced
    before the value computation of the result of the operator.

-- 
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]

#66590

On Thursday, July 30, 2015 at 5:03:55 PM UTC-5, Keith Thompson wrote:
> John Bode <jfbode1029@gmail.com> writes:
> [...]
> > So, let's talk about order of evaluation.
> >
> > Assume the statement:
> >
> >     a = b + c * d;
> >
> > The order in which b, c, and d are evaluated is unspecified.  Let's consider
> > things which might influence evaluation order.  
> [...]
> > Then there's the instruction set to consider; on x86, it makes more sense
> > to do the multiplication followed by the add, so it makes sense to evaluate
> > c and d before b.  That may not be true on other architectures. 
> [...]
> 
> The addition *cannot* be performed until the result of the
> multiplication is known.  b, c, and d (which may be complex
> subexpressions) can be evaluated any any of the 6 possible orders, but
> the evaluations of c and d must precede the multiplication, and the
> multiplication and evaluation of b must precede the addition.
> 

Derp.

Let me try that again without sounding like a complete idiot (no 
guarantees).

What I *meant* to say (really!) is that by evaluating c and d before b,
you can streamline your register use, such as

    movl c, %eax
    imull d, %eax
    addl b, %eax

whereas if you evaluate b first, it has to hang around in another register
not being used while the multiplication is happening:

    movl b, %edx
    movl c, %eax
    imull d, %eax
    addl %edx, %eax

(in reality, b, c, and d would actually be offsets from the frame pointer).

[toc] | [prev] | [next] | [standalone]

#66593

On Thursday, July 30, 2015 at 2:21:13 PM UTC-7, John Bode wrote:
> On Wednesday, July 15, 2015 at 11:19:24 PM UTC-5, David Kleinecke wrote:
> > On Tuesday, July 14, 2015 at 11:57:50 AM UTC-7, James Kuyper wrote:
> > > On 07/14/2015 12:29 PM, James Kuyper wrote:
> > > > On 07/14/2015 12:16 PM, David Kleinecke wrote:
> > > > ...
> > > >> OK. I admit that it never occurred to me that anyone would object
> > > >> to better documentation as a goal.
> > > > 
> > > > We don't. We object to making documentation worse by including in it
> > > > things that don't need to be documented, and which might make the
> > > > documentation unreadably complicated and unacceptably difficult to create.
> > > 
> > > Note, in particular, that we're willing to consider the possibility that
> > > we're wrong about any particular items not needing to be documented.
> > > We're willing to listen to your explanation why documenting these things
> > > would make the documentation better (as opposed to merely bigger). I
> > > can't guarantee that we'll agree when we've heard your reasons - but
> > > we'll never have even a chance of learning that we were wrong unless you
> > > articulate your reasons - and we've repeatedly requested that you give
> > > us that chance.
> > 
> > And I have repeatedly said my reason is that I want everything 
> > documented and you wont accept that as a reason. You have not
> > stated any clearer opposition to that principle other than that 
> > it is too much trouble.  
> >  
> 
> > > Realistically, the fact that you've repeatedly refused the request, the
> > > fact that you don't even seem to understand the request, creates the
> > > strong suspicion that you are incapable of articulating a reason. 
> > 
> > You don't seem to recognize a reason when you see one. 
> 
> "I want it" is not a *good* reason.
> 
> "I am writing code where knowing the order in which static objects are
> initialized allows me to gain performance" is a decent reason.
> 
> > 
> > > If you could, you would probably already have done so. You seem so firmly
> > > convinced that no justification is needed for any documentation, that
> > > you've probably never even thought about what a proper argument
> > > justifying such a requirement would look like. Nonetheless, should you
> > > ever manage to come up with such an argument, I encourage you to present
> > > it. We'll probably find it full of holes, but I think that all of us
> > > will learn something from the process.
> > > 
> > > Let's put it this way: I insist that you provide full documentation of
> > > how you spent the past week. More documentation is always better, right?
> > > So you should have no objection to providing it - but of course, I'm
> > > pretty sure that you would object. Even if nothing happened last week
> > > that you would consider private, I'm sure you'd at least object to doing
> > > the work required to put that documentation together - if you don't have
> > > anything better to do with your time, you must be pretty bored.
> > > 
> > > What kind of argument would your want me to give you, in order to
> > > convince you to produce such documentation? There certainly are
> > > arguments that I could present you to justify such a request (for
> > > instance, you could be a suspect in a criminal investigation, and I
> > > could be a policeman with relevant jurisdiction). After thinking about
> > > that for awhile, maybe you'll have a better idea how to present an
> > > argument why the things the standard says are unspecified should be
> > > documented.
> > 
> > This is a tempest in a teapot. 
> > 
> > I believe that the purpose of the kind of documentation I believe is
> > needed is to describe what one can expect a machine (in the abstract
> > sense - a comiler to be exact) to do. Your attempt to compare that with
> > a what I would call a log of events is laughable.
> > 
> > If we want a clear debate let us try this:
> > 
> >    Resolved a C compiler shall document what is does to a source
> >    program in every detail including cases where more than one
> >    outcome is possible. 
> > 
> > I visualize myself as FOR and you as AGAINST.
> > 
> > Now it is your turn.
> 
> So, let's talk about order of evaluation.
> 
> Assume the statement:
> 
>     a = b + c * d;
> 
> The order in which b, c, and d are evaluated is unspecified.  Let's consider
> things which might influence evaluation order.  
> 
> Suppose the prior statement is
> 
>     b = d - 1;
> 
> b and d have *already been evaluated*; assuming a modern processor with
> multiple general purpose data registers, those values will already be
> available, so the only thing that *really* needs to be evaluated is in
> the current statement is c.
> 
> However, if the prior statement is
> 
>     c = 5;
> 
> then c has already been evaluated, so both b and d need to be evaluated for
> the current statement.
> 
> So order of evaluation may depend on prior statements and evaluations.  Of
> course, since you want this documented "in every detail", you'd have to
> consider all possible permutations of prior statements.  
> 
> Then there's the instruction set to consider; on x86, it makes more sense
> to do the multiplication followed by the add, so it makes sense to evaluate
> c and d before b.  That may not be true on other architectures. 
> 
> So order of evaluation may depend on the instruction set.  Since some 
> compilers like gcc have been ported to different architectures, they'd
> have to list all possible permutations of evaluation order based on 
> the architecture, in addition to all possible permutations of prior 
> statements above.  
> 
> Note that we haven't even discussed side effects: imagine a statement
> like
> 
>     a = b++ + --c * d++;
> 
> that could also play a role in determining evaluation order.  
> 
> Now imagine that b, c, and d are different arithmetic types (int, float,
> double, etc.).  That's another thing that could potentially affect
> evaluation order.  
> 
> Documenting all possible permutations of evaluation order based on 
> instruction sets, prior code, and other factors would be a *massive*
> pain in the ass.  When faced with that kind of a documentation burden, 
> I expect most implementors would simply say, "screw it, we'll do it the 
> Java/C# way, optimization be damned". 
> 
> And, assuming you actually *read* that documentation, is that going to
> affect how you write your code?  Are you going to try to micro-optimize 
> for a particular platform, at the expense of portability? 
> 
> I asked this before: have you run into a situation where the performance
> or correctness of your code suffered because you didn't know the *exact*
> behavior picked by the implementation?  If you have, then demanding some
> level of documentation may be reasonable.  Otherwise, you just want a po

I would imagine you are looking for an answer. You said too many things 
for a detailed answer - so here goes on a generalized one:

I assume there is a natural order in expression evaluation. It's not
what I write but there is defined algorithm for deriving the evaluation.
The algorithm is based on the usual precedences and assocativity. An
optimizer must preserve the effective order of evaluation.

I never suggested the optimizer needs to be documented. There is some
optimization that is machine-independent but that need not be documented.
Or rather the documentation says nothing but "The optimizer may change
or re-arrange the coded instructions but does not change the effective
calculation." It had better do just that.

If, for example, the arguments to a function were always evaluated in
the order they were written it would be useful to know. Compare
    x = f(g(a),h(b))
and 
    p = g(a)
    q = h(b)
    x = f(p,q)
These would be identical is a naive compiler pre-optimization. The
optimizer can't reverse the order unless it knows here are no 
side-effects in g and h. The optimizer cannot easily know which of 
these two forms was original. It cannot reverse the g/h calls in the
second form and it would have to take special measures to recognize 
the first form and allow them to be reversed. 

[toc] | [prev] | [next] | [standalone]

#66595

On 07/30/2015 07:46 PM, David Kleinecke wrote:
...
> 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.

> ... It's not
> what I write but there is defined algorithm for deriving the evaluation.
> The algorithm is based on the usual precedences and assocativity. An
> optimizer must preserve the effective order of evaluation.
> 
> I never suggested the optimizer needs to be documented. ...

You said  that "everything" must be documented, and that you opposed all
of the unspecified behavior in the C standard. Two of the key items of
unspecified behavior listed the C standard involve the order of
evaluation of C expressions. The order is not completely unspecified,
but to the extent that it is, an optimizer can rearrange the order.
Therefore, if the order of operations can no longer be unspecified, but
must instead be implementation-defined, then it follows that the
optimizer needs to be documented.

> ... There is some
> optimization that is machine-independent but that need not be documented.
> Or rather the documentation says nothing but "The optimizer may change
> or re-arrange the coded instructions but does not change the effective
> calculation." It had better do just that.

You've just re-invented the as-if rule. Order of operations only matters
when it DOES change the effective calculation, by reason of re-ordering
the side-effects. The as-if rule already covers the more limited
optimizations you're talking about.

> If, for example, the arguments to a function were always evaluated in
> the order they were written it would be useful to know. Compare
>     x = f(g(a),h(b))
> and 
>     p = g(a)
>     q = h(b)
>     x = f(p,q)
> These would be identical is a naive compiler pre-optimization. The
> optimizer can't reverse the order unless it knows here are no 
> side-effects in g and h. The optimizer cannot easily know which of 
> these two forms was original. It cannot reverse the g/h calls in the
> second form and it would have to take special measures to recognize 
> the first form and allow them to be reversed. 

C's unspecified order of operations allows for the rearranged order to
have consequences as a result of side-effects. Making the order
unspecified is intended to discourage the writing of code that just
happens to have the desired order of evaluation. It's supposed to make
your code clearer by forcing you to explicitly specify the desired order.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#66623

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. 

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). 

I admit there are other ways of doing the arithmetic. They just aren't       
the natural way. But they may be more efficient.

[toc] | [prev] | [next] | [standalone]

#66628

David Kleinecke <dkleinecke@gmail.com> writes:
> On Thursday, July 30, 2015 at 9:59:20 PM UTC-7, James Kuyper 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.

A sub-expression is an expression that's part of another 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. 

In C, the expressions
    a + b + c
and
    (a + b) + c
have exactly the same meaning, regardless of what you might think is
"natural".  The subexpressions a, b, and c may be evaluated in any
of the 6 possible orders; if they have side effects, those side
effects may occur in any of those 6 possible orders.  The standard
expresses no preference whatsoever for which of the 6 orders should
be chosen.

In the abstract machine, the first "+" is evaluated after the
results of evaluating a and b are determined, and the second "+"
is evaluated after the results of a, b, c, and the first "+"
are determined.  A compiler may generate code that does these
evaluations in a different order if and only if the change doesn't
alter the observable behavior.  (There's no such restriction on
variant orderings of evaluating a, b, and c.)

This is all essentially the same in C90, C99 and C11.

That's (part of) how expression evaluation is defined in C.  If you
want to discuss it (how you think it *should* work, what you think
should be documented, etc.), you should at least understand how
it's currently defined.

> 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). 
>
> I admit there are other ways of doing the arithmetic. They just aren't       
> the natural way. But they may be more efficient.

You haven't defined what you mean by "natural".

-- 
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]

#66631

On 07/31/2015 08: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.

A sub-expression is any expression that is one operand of another
expression. A sub-expression can have sub-expressions of it's own/ For
example, the expression --p->mem[a]++ 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

> 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

That way of parsing that expression is mandated by the C standard; but
it is in no way any more natural than a + (b + c). The standard could
just as easily have chosen the second parse. That the two parses are
mathematically equivalent is presumably the "well known theorem" that
you're talking about; but that theorem doesn't apply to computer
arithmetic; one of them might overflow or underflow during the
intermediate calculation, while the other might not. On some systems
that might not matter - on others, overflow might result in a signal
being raised. That's one key reason why the C standard has to choose one
order or the other. I know that INT_MAX + INT_MIN - 3567 does not
underflow, only because I know that the standard mandates that it be
parsed as (INT_MAX + INT_MIN) - 3567.

The parse tree constrains the order of evaluation, but it does not
uniquely determine it. There are 5 expressions that need to be
evaluated; I'll label them A-E:

	A: a
	B: b
	C: c
	D: a+b
	E: (a+b) + c

The parse tree requires that A and B be evaluated before D. It also
requires that C and D be evaluated before E. The order of evaluation is
otherwise completely unspecified. All of the following orders are permitted:

	A, B, C, D, E
	A, C, B, D, E
	C, A, B, D, E
	C, B, A, D, E
	B, C, A, D, E
	B, A, C, D, E
	A, B, D, C, E
	B, A, D, C, E

The order of evaluation only matters, however, for expressions with
side-effects. Addition never has side effects. Evaluation of a variable
only has side-effects if that variable's definition is
volatile-qualified. That's why, when discussing order of evaluation, I
normally prefer to use function calls as the lowest-level expression,
because it's easier to understand that a function call might have a
side-effect - so my version of this example would be a() + b() + c().

If none of the variables are volatile qualified, all eight permitted
orders are equivalent. On the other hand, if a, b, and c are all
volatile qualified, then there are six meaningfully different orders of
evaluation:

	A, B, C
	A, C, B
	C, A, B
	B, C, A
	B, A, C

Which is still a larger number than the three you orders of evaluation
that you referred to. I'm curious which three orders you were talking
about - could you list them?

> You may not have encountered this use of the word "natural" before. It
> means naively obvious. 

Oh, I've run into it before - and what seems naively obvious to one
person may not seem obvious at all to another person. The idea that
there's one "natural" order is a fiction of the same type as as the
concept of "common sense", which is neither common nor, necessarily,
sensible.

Evaluating a+b+c as (a+b)+c may seem obvious to you, but to me it's no
more obvious than a+(b+c). The first one is relevant, and the second one
is not, but only because the C standard says so, not because it's any
more obvious than the other one. That you feel one of them is more
obvious is just your personal bias.

> Natural does not mean "required". An optimizer can juggle the order
> freely (within the obvious limitation). 

The limitations are far from obvious, and the standard goes to great
lengths to clearly specify which limitations apply, and which do not, to
avoid confusion. Your previous comments make it clear that you believe
that a limitation "does not change the final result" should apply. The C
standard imposes no such limitation. Instead, when the order does
matter, and the limitations that C does impose are not sufficient to
guarantee an acceptable order, it's the developer's responsibility to
re-write the code so that an acceptable order is mandatory.

What the C standard fails to specify about the order is intended to
force developers to be clear about the order when it matters, and to
allow implementations to optimize the order based upon the unchecked
assumption that it doesn't matter if the developer chooses not to be
clear about it. If the standard took your approach, they could only make
such optimizations after checking whether that assumption was correct.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#66845

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.

[toc] | [prev] | [next] | [standalone]

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web