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

Groups > comp.lang.c > #65686

Re: Unspecified Behaviors in C90 - part 3

Show all headers | View raw

On 16/07/15 03:38, David Kleinecke wrote:
> On Tuesday, July 14, 2015 at 10:09:00 AM UTC-7, Richard Heathfield wrote:
>> On 14/07/15 17:33, David Kleinecke wrote:
>>
>> > Not quite - but close. The things listed as unspecified are unspecified
>> > in different ways and I would like those ways separated. For example,
>> > the behavior if a printable character is written when the active
>> > position is at the final position of a line is unspecified because the
>> > standard is declining to specify the display device but could (and
>> > should) be documented for any real device.
>>
>> So we have two choices that I can see - document the behaviour of the
>> display device in the display device documentation, or document the
>> behaviour of all existing display devices in the Standard (or in the
>> implementation's documentation), and update the Standard (or the
>> implementation docs) every time a new display device is brought to
>> market. If we take the latter course, the Standard (or *every*
>> implementation document) immediately increases in length by a
>> significant amount, and is almost always out of date. If we adopt the
>> former course, people who actually need to know about the
>> characteristics of a specific display device can look up those
>> characteristics easily, without burdening the rest of the world with
>> redundant data. So you are making a good argument for leaving some
>> things unspecified. What advantage do you see in forcing implementers to
>> document the behaviour of display devices?
>
> I believe that what you say does not follow. As I see it, the whole
> current display device philosophy (5.2.2 and elsewhere) should be
> replaced. I have not thought through by exactly what. But, in any
> case the Standard should be LESS specific than it is today

Oh, I'm sorry. I thought you were arguing for more documentation. Now it 
turns out you want less. Which bits do you think it should leave out?

>
>> > On the other hand the order of evaluation of arguments needs to be
>> > documented because perhaps the order is predictable.
>>
>> If the order is predictable, you don't need to document it because you
>> can just predict it instead. In fact, the order is not predictable (in
>> the sense that more than one reasonable choice can be made and
>> implementers do in fact make different choices on occasion), but it
>> turns out not to matter because well-written C code doesn't depend on
>> order of evaluation (between sequence points).
>
> What about
>      y = f(g(x),h(x));
> where g and h have different non-commutive side-effects on something
> else? Say g(x) = {y=y+2} and h(x) = {y=3*y}

As I said, well-written C code does not rely on order of evaluation. 
What you have there is not well-written C code. Decide on the order of 
evaluation you want, and then write the C in such a way that that is 
what you get, regardless of how the compiler generates the code.

>> > A blanket statement is too simple but brief statements will usually
>> > suffice.
>>
>> Why is a blanket statement too simple? It seems to me to be perfectly
>> reasonable for the Standard to identify a number of areas in which there
>> is no need to specify a precise behaviour (e.g. order of evaluation),
>> and simply label these areas "unspecified behaviour". That's what the
>> Standard does right now. It works. If you want either ISO or
>> implementers to change the way they do things, you will need more
>> powerful arguments than you have so far supplied.
>
> I can always hope. Perhaps the Standard committe members would agree if
> they thought to consider the matter. I want to remind them.

You can always hope... that they'll listen to you even though you 
haven't advanced any reason why they should? Good luck with that.

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

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