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

Groups > comp.lang.c > #65935

Re: Unspecified Behaviors in C90 - part 3

Show all headers | View raw

On 07/14/2015 11:21 AM, David Kleinecke wrote:
> On Monday, July 13, 2015 at 2:22:53 PM UTC-7, Richard Bos wrote:
...
>> These behaviours are unspecified precisely because they are _not_ of
>> interest to the programmer. Note that this is stronger than "you need
>> not care about this": it's closer to "you _should_ not care about this".
>> If you start delving into the details of unspecified behaviour, you are
>> on a hiding to nothing; worse, you are setting yourself up to be trapped
>> by over-optimisations that break.
>  
> I agree. The confusing part seems to be that people jump to the
> conclusion that documentation means a full description.

Sorry about this late response. I had a thought about that message that
didn't gel until long after I had read it, and I haven't had the time to
track it down since then. Richard Bos's recent response to this same
message made it easier to find.

The reason people "jump to th[at] conclusion" is because it's basically
correct, in the context of the C standard.

The standard defines implementation-defined behavior as "unspecified
behavior where each implementation documents how the choice is made".
There's a lot of things the standard doesn't say about this
documentation. It could be stored in a secure location, and it might
cost you a billion dollars to get permission to read it. The standard
doesn't require that the documentation be comprehensible to the reader.
It doesn't have to be written in any language the reader knows how to
read. It doesn't have to be in any language that any person still living
knows how to read :-). For that matter, it could be oral documentation,
recorded in English with a Russian accent so thick that even people who
were fluent in both languages would be unable to understand it.

However, despite all the things the standard doesn't say about the
documentation, it is implied that the documentation must be accurate: if
it's inaccurate, then what's been documented is something other than
"how the choice was made". It must be basically complete, any
incompleteness would mean that part of "how the choice was made" would
not be documented. If the language of the documentation is in fact one
that nobody knows how to read :-) , then there will be no way to
determine whether the implementation has met that part of its
conformance requirements  - but those requirements still apply.

There are exceptions to this. For instance, 5.2.4.2.2p6 says "The
implementation may state that the accuracy is unknown." There's an old
saying, the "the exception proves the rule", which is, of course,
nonsense according to modern English usage of those words. But a recent
discussion in this newsgroup revealed that the origin of the saying
could have been translated more accurately into modern English by saying
"The exception proves the existence of a rule".
In this case, 5.2.4.2.2p6 is an exception that implies that the general
rule is that the documentation required for implementation-defined
behavior is normally required to be complete - it must actually document
everything that the standard requires it to document. The only reason
it's allowed to wimp out on floating point accuracy is because the
standard makes an explicit exception for that case. No exception would
be needed if "X is unknown" was normally allowed as documentation for
everything.

So, you're suggesting that the standard should a) require that more
things be documented but b) should not require that the things which are
documented be meaningfully documented? While that would substantially
reduce the workload of implementors, what good would it do? If adopted
as a general principle, it implies that none of an implementation's
mandatory documentation need be complete. Do you really want to
encourage incomplete documentation? I thought that your basic
preferences were in the opposite direction.

Back to comp.lang.c | Previous | Next — Previous 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