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


Groups > comp.lang.c > #65580

Re: Unspecified Behaviors in C90 - part 3

From James Kuyper <jameskuyper@verizon.net>
Newsgroups comp.lang.c
Subject Re: Unspecified Behaviors in C90 - part 3
Date 2015-07-14 15:11 -0400
Organization A noiseless patient Spider
Message-ID <mo3mq2$8g9$1@dont-email.me> (permalink)
References <cc105b32-29a2-40ee-8eef-feaef5ee8560@googlegroups.com> <55a42b8f.25228343@news.xs4all.nl> <435cc143-4ce0-4b10-a25b-92b0a638d9e6@googlegroups.com> <lnio9mloyl.fsf@kst-u.example.com> <d5963c50-6159-4137-940d-f5d08a0a257e@googlegroups.com>

Show all headers | View raw


On 07/14/2015 12:33 PM, David Kleinecke wrote:
...
> On the other hand the order of evaluation of arguments needs to be
> documented because perhaps the order is predictable. 

So? With an modern compiler with an aggressive optimizer, by far the
quickest way to predict what order will be used would be to compile the
program, and find out which order was actually used by examining the
generated program.

But let's assume for the moment that it is possible to provide a simple
accurate statement of how the order is determined - what use would that
be? One of the key reasons for making the order unspecified is to
discourage people from writing code where the order matters. If it does
matter, explicitly evaluate all but one of the arguments in the order
that you want, storing the results in temporary variables, and then pass
those variables as arguments. That's much clearer, and the order is
guaranteed.

If you follow those guidelines, what value would you gain from being
able to read documentation of the actual order?

> A blanket statement is too simple but brief statements will usually
> suffice. 

We're not asking for a blanket statement - if there were valid
justification for mandating documentation of all those items, I'd expect
it be a very different justification for each item.

However, brief statements won't be sufficient, either - at least, not if
those are examples of what you mean by "brief statements". They are far
too brief, and don't really work, either.
-- 
James Kuyper

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-09 11:21 -0700
  Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-09 14:54 -0400
    Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 21:38 +0100
  Re: Unspecified Behaviors in C90 - part 3 raltbos@xs4all.nl (Richard Bos) - 2015-07-13 21:22 +0000
    Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 08:21 -0700
      Re: Unspecified Behaviors in C90 - part 3 Keith Thompson <kst-u@mib.org> - 2015-07-14 08:48 -0700
        Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 09:33 -0700
          Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-14 18:08 +0100
            Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 19:38 -0700
              Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 00:47 -0400
                Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:10 -0700
                Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 21:17 -0400
                Re: Unspecified Behaviors in C90 - part 3 maddoxr@acm.org - 2015-07-17 07:43 -0700
              Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-16 09:35 +0100
                Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:18 -0700
                Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:45 +0100
                Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 21:19 -0400
                Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-17 12:14 -0400
                Re: Unspecified Behaviors in C90 - part 3 Keith Thompson <kst-u@mib.org> - 2015-07-17 11:00 -0700
                Re: Unspecified Behaviors in C90 - part 3 raltbos@xs4all.nl (Richard Bos) - 2015-07-19 21:24 +0000
              Re: Unspecified Behaviors in C90 - part 3 Keith Thompson <kst-u@mib.org> - 2015-07-16 07:40 -0700
                Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:20 -0700
                Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:49 +0100
          Re: Unspecified Behaviors in C90 - part 3 Keith Thompson <kst-u@mib.org> - 2015-07-14 11:23 -0700
          Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-14 15:11 -0400
            Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 19:46 -0700
              Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 01:50 -0400
                Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:15 -0700
                Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:39 +0100
                Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 22:26 -0400
      Re: Unspecified Behaviors in C90 - part 3 raltbos@xs4all.nl (Richard Bos) - 2015-07-19 21:22 +0000
      Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-19 17:57 -0400

csiph-web