Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #64878 > unrolled thread
| Started by | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| First post | 2015-07-07 14:44 -0700 |
| Last post | 2015-07-07 22:30 -0400 |
| Articles | 20 on this page of 131 — 17 participants |
Back to article view | Back to comp.lang.c
Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-07 14:44 -0700
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-07 15:34 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-08 08:47 -0700
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-08 09:11 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-08 10:24 -0700
Re: Unspecified behavior in C John Bode <jfbode1029@gmail.com> - 2015-07-08 10:46 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-08 13:54 -0400
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-08 11:12 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-09 09:15 -0700
Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 17:33 +0100
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-10 09:24 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-10 12:54 -0400
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-09 10:58 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-10 09:33 -0700
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-10 12:11 -0700
Re: Unspecified behavior in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 21:05 +0000
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-10 17:14 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-11 09:32 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-11 12:59 -0400
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-11 17:21 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-11 09:23 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-11 13:03 -0400
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-11 17:15 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-12 09:52 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-12 14:13 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-13 09:02 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-13 13:18 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-13 11:09 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-13 15:06 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 08:14 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-14 12:02 -0400
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-13 12:03 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 07:54 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-14 11:16 -0400
Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-14 16:17 +0100
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 09:16 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-14 12:29 -0400
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-14 14:57 -0400
Re: Unspecified behavior in C Öö Tiib <ootiib@hot.ee> - 2015-07-14 13:12 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-14 16:30 -0400
Re: Unspecified behavior in C Öö Tiib <ootiib@hot.ee> - 2015-07-14 15:54 -0700
Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-14 21:41 -0500
Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-14 21:51 -0500
Re: Unspecified behavior in C Öö Tiib <ootiib@hot.ee> - 2015-07-15 12:42 -0700
Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-15 16:13 -0500
Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-16 08:49 -0500
Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 10:10 -0700
Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-20 13:24 -0500
Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 02:56 -0700
Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-23 11:26 -0500
Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-26 11:24 -0700
Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-23 19:03 -0500
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 21:19 -0700
Re: Unspecified behavior in C Martin Shobe <martin.shobe@yahoo.com> - 2015-07-15 23:45 -0500
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-16 01:37 -0400
Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-16 09:42 +0100
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:05 -0700
Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:32 +0100
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-16 21:07 -0400
We're good - don't you worry 'bout a thing, babe (Was: Unspecified behavior in C) gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-17 07:21 +0000
Re: Unspecified behavior in C raltbos@xs4all.nl (Richard Bos) - 2015-07-19 20:59 +0000
Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-19 22:02 +0100
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-16 17:59 -0400
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-16 23:09 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-17 18:48 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-17 23:09 -0400
Re: Unspecified behavior in C raltbos@xs4all.nl (Richard Bos) - 2015-07-19 20:57 +0000
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-19 17:22 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-19 18:57 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-19 22:16 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-19 19:30 -0700
Re: Unspecified behavior in C John Bode <jfbode1029@gmail.com> - 2015-07-30 14:20 -0700
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-30 15:30 -0700
Re: Unspecified behavior in C John Bode <jfbode1029@gmail.com> - 2015-07-30 15:53 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-30 16:46 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-31 00:59 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-31 17:15 -0700
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-31 18:28 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-31 23:28 -0400
Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 04:07 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-08-04 18:02 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-04 21:27 -0400
Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-24 09:33 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-08-24 17:11 -0700
Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 12:44 -0700
Re: Unspecified behavior in C Ken Brody <kenbrody@spamcop.net> - 2015-08-03 12:09 -0400
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-03 13:26 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-08-03 17:53 -0700
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-08-03 18:44 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-08-04 17:59 -0700
Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-08-05 02:23 +0100
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-04 21:39 -0400
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-08-04 19:27 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-04 00:25 -0400
Re: Unspecified behavior in C Ken Brody <kenbrody@spamcop.net> - 2015-08-04 11:55 -0400
Re: Unspecified behavior in C Philip Lantz <prl@canterey.us> - 2015-08-04 10:31 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-04 13:32 -0400
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-04 22:46 -0400
Re: Unspecified behavior in C Ken Brody <kenbrody@spamcop.net> - 2015-08-10 12:16 -0400
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-10 13:26 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-08-03 17:46 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-05 12:34 -0400
Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-14 17:57 +0100
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 10:31 -0700
Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-14 18:50 +0100
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 20:59 -0700
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-14 11:34 -0700
Re: Unspecified behavior in C raltbos@xs4all.nl (Richard Bos) - 2015-07-19 20:46 +0000
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-12 12:07 -0700
Re: Unspecified behavior in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 19:53 +0000
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-12 16:12 -0400
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-09 14:20 -0400
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-09 12:18 -0700
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-10 09:47 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-10 13:36 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-11 09:19 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-11 12:56 -0400
Re: Unspecified behavior in C gordonb.j19di@burditt.org (Gordon Burditt) - 2015-07-11 20:36 -0500
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-12 10:10 -0700
Re: Unspecified behavior in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 20:13 +0100
Re: Unspecified behavior in C raltbos@xs4all.nl (Richard Bos) - 2015-07-09 11:17 +0000
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-08 10:37 -0700
Re: Unspecified behavior in C John Bode <jfbode1029@gmail.com> - 2015-07-08 10:51 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-08 14:14 -0400
Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-08 12:19 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-08 12:14 -0400
Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-08 10:40 -0700
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-08 14:29 -0400
Re: Unspecified behavior in C raltbos@xs4all.nl (Richard Bos) - 2015-07-09 11:20 +0000
Re: Unspecified behavior in C Robert Wessel <robertwessel2@yahoo.com> - 2015-07-09 02:30 -0500
Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-07 22:30 -0400
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-11 09:23 -0700 |
| Message-ID | <37753968-e7fd-4076-9451-ed27b66a7330@googlegroups.com> |
| In reply to | #65179 |
On Friday, July 10, 2015 at 12:11:53 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Thursday, July 9, 2015 at 10:58:46 AM UTC-7, Keith Thompson wrote: > >> David Kleinecke <dkleinecke@gmail.com> writes: > [...] > >> > You are correct. I want all the "unspecified" behavior documented. > >> > >> Thank you for the clear statement. > >> > >> I strongly disagree. > > [snip examples] > > > I think you don't understand what I mean by documented. I just want > > what may happened stated. All I want for, say, the order of arguments > > is that there is a statement in the documentation like "the order > > in which the arguments of a function are evaluated is unpredicatable." > > That is useful because an implementation might make them predicatable. > > At the moment the documentation is not required to say anything on this > > subject. > > For the order to be truly *unpredictable*, it would have to use some > high-quality random number generator to determine the order on each > call. Is that really what you meant? > > In practice, the order is arbitrary, and may change depending on factors > that are not at all obvious. > > I am perfectly satisfied with the standard's statement that the order is > unspecified (and I'm glossing over the possibility that evaluation could > be interleaved, since there are no sequence points between argument > evaluations). > > If an implementation documented the order as "unpredictable", how would > you benefit from that information? > > If gcc, for example, provided documentation that specified exactly how > the order is determined (for a given release, target platform, and > optimization level), how would you benefit from that information? > > If the documentation merely stated that the order is unspecified, would > that satisfy you? If so, what's the point? That's exactly what the > standard already says. You are assuming the standard is part of the documentation. I suppose that is fair enough but it wasn't my assumption. Perhaps I should add it. I would be much more willing to make that assumption if the standard were better written.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-11 13:03 -0400 |
| Message-ID | <55A14C50.7090901@verizon.net> |
| In reply to | #65304 |
On 07/11/2015 12:23 PM, David Kleinecke wrote: > On Friday, July 10, 2015 at 12:11:53 PM UTC-7, Keith Thompson wrote: ... >> If the documentation merely stated that the order is unspecified, would >> that satisfy you? If so, what's the point? That's exactly what the >> standard already says. > > You are assuming the standard is part of the documentation. ... The C standard is part of the documentation of the C language. It is not necessarily part of the documentation of any particular implementation of C - there's certainly no requirement that it be a part. Some implementations provide copies of the C standard with the compiler. Others only incorporate it by reference. Some only imply a connection, by way of saying something like "conforms to the C99 standard".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-11 17:15 -0700 |
| Message-ID | <lnsi8unscq.fsf@kst-u.example.com> |
| In reply to | #65304 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Friday, July 10, 2015 at 12:11:53 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > On Thursday, July 9, 2015 at 10:58:46 AM UTC-7, Keith Thompson wrote:
>> >> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>> >> > You are correct. I want all the "unspecified" behavior documented.
>> >>
>> >> Thank you for the clear statement.
>> >>
>> >> I strongly disagree.
>>
>> [snip examples]
>>
>> > I think you don't understand what I mean by documented. I just want
>> > what may happened stated. All I want for, say, the order of arguments
>> > is that there is a statement in the documentation like "the order
>> > in which the arguments of a function are evaluated is unpredicatable."
>> > That is useful because an implementation might make them predicatable.
>> > At the moment the documentation is not required to say anything on this
>> > subject.
>>
>> For the order to be truly *unpredictable*, it would have to use some
>> high-quality random number generator to determine the order on each
>> call. Is that really what you meant?
>>
>> In practice, the order is arbitrary, and may change depending on factors
>> that are not at all obvious.
>>
>> I am perfectly satisfied with the standard's statement that the order is
>> unspecified (and I'm glossing over the possibility that evaluation could
>> be interleaved, since there are no sequence points between argument
>> evaluations).
>>
>> If an implementation documented the order as "unpredictable", how would
>> you benefit from that information?
>>
>> If gcc, for example, provided documentation that specified exactly how
>> the order is determined (for a given release, target platform, and
>> optimization level), how would you benefit from that information?
>>
>> If the documentation merely stated that the order is unspecified, would
>> that satisfy you? If so, what's the point? That's exactly what the
>> standard already says.
>
> You are assuming the standard is part of the documentation. I
> suppose that is fair enough but it wasn't my assumption. Perhaps
> I should add it. I would be much more willing to make that
> assumption if the standard were better written.
You've answered none of the questions I asked. Did you intend to?
The standard documents the language. The documentation for a
particular implementation is likely to be useless without that
knowledge.
The C standard says that the order of evaluation of function
arguments is unspecified. It also explains clearly what
"unspecified" means. Apparently that's not good enough for you,
but you haven't explained why.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-12 09:52 -0700 |
| Message-ID | <cbd1f5ff-cad1-4558-855a-980a4691063b@googlegroups.com> |
| In reply to | #65374 |
On Saturday, July 11, 2015 at 5:15:58 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Friday, July 10, 2015 at 12:11:53 PM UTC-7, Keith Thompson wrote: > >> David Kleinecke <dkleinecke@gmail.com> writes: > >> > On Thursday, July 9, 2015 at 10:58:46 AM UTC-7, Keith Thompson wrote: > >> >> David Kleinecke <dkleinecke@gmail.com> writes: > >> [...] > >> >> > You are correct. I want all the "unspecified" behavior documented. > >> >> > >> >> Thank you for the clear statement. > >> >> > >> >> I strongly disagree. > >> > >> [snip examples] > >> > >> > I think you don't understand what I mean by documented. I just want > >> > what may happened stated. All I want for, say, the order of arguments > >> > is that there is a statement in the documentation like "the order > >> > in which the arguments of a function are evaluated is unpredicatable." > >> > That is useful because an implementation might make them predicatable. > >> > At the moment the documentation is not required to say anything on this > >> > subject. > >> > >> For the order to be truly *unpredictable*, it would have to use some > >> high-quality random number generator to determine the order on each > >> call. Is that really what you meant? > >> > >> In practice, the order is arbitrary, and may change depending on factors > >> that are not at all obvious. > >> > >> I am perfectly satisfied with the standard's statement that the order is > >> unspecified (and I'm glossing over the possibility that evaluation could > >> be interleaved, since there are no sequence points between argument > >> evaluations). > >> > >> If an implementation documented the order as "unpredictable", how would > >> you benefit from that information? > >> > >> If gcc, for example, provided documentation that specified exactly how > >> the order is determined (for a given release, target platform, and > >> optimization level), how would you benefit from that information? > >> > >> If the documentation merely stated that the order is unspecified, would > >> that satisfy you? If so, what's the point? That's exactly what the > >> standard already says. > > > > You are assuming the standard is part of the documentation. I > > suppose that is fair enough but it wasn't my assumption. Perhaps > > I should add it. I would be much more willing to make that > > assumption if the standard were better written. > > You've answered none of the questions I asked. Did you intend to? Most of your questions appear rhetorical to me. I don't answer rhetorical questions. > > The standard documents the language. The documentation for a > particular implementation is likely to be useless without that > knowledge. > > The C standard says that the order of evaluation of function > arguments is unspecified. It also explains clearly what > "unspecified" means. Apparently that's not good enough for you, > but you haven't explained why. It doesn't explain what "unspecified" means other than undocumented implementation-defined. I have suggested already that these should be documented just like all the other implemenation-defined features. And I have stated repeatedly that I want everything documented.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-12 14:13 -0400 |
| Message-ID | <55A2AE38.3010002@verizon.net> |
| In reply to | #65421 |
On 07/12/2015 12:52 PM, David Kleinecke wrote:
> On Saturday, July 11, 2015 at 5:15:58 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>>> On Friday, July 10, 2015 at 12:11:53 PM UTC-7, Keith Thompson wrote:
...
>>>> For the order to be truly *unpredictable*, it would have to use some
>>>> high-quality random number generator to determine the order on each
>>>> call. Is that really what you meant?
>>>>
>>>> In practice, the order is arbitrary, and may change depending on factors
>>>> that are not at all obvious.
>>>>
>>>> I am perfectly satisfied with the standard's statement that the order is
>>>> unspecified (and I'm glossing over the possibility that evaluation could
>>>> be interleaved, since there are no sequence points between argument
>>>> evaluations).
>>>>
>>>> If an implementation documented the order as "unpredictable", how would
>>>> you benefit from that information?
>>>>
>>>> If gcc, for example, provided documentation that specified exactly how
>>>> the order is determined (for a given release, target platform, and
>>>> optimization level), how would you benefit from that information?
>>>>
>>>> If the documentation merely stated that the order is unspecified, would
>>>> that satisfy you? If so, what's the point? That's exactly what the
>>>> standard already says.
>>>
>>> You are assuming the standard is part of the documentation. I
>>> suppose that is fair enough but it wasn't my assumption. Perhaps
>>> I should add it. I would be much more willing to make that
>>> assumption if the standard were better written.
>>
>> You've answered none of the questions I asked. Did you intend to?
>
> Most of your questions appear rhetorical to me. I don't answer
> rhetorical questions.
They weren't.
For instance, "how would you benefit from that information?" Keith and I
see no way to benefit from that information, and therefore no reason to
require that it be documented. You insist that it should be documented,
which implies that you might believe it could be beneficial to have it.
If you're right about that, explaining the benefit to us would be
helpful in convincing us (and many other people) that it should be
required. If you're wrong, explaining the benefit that you incorrectly
expect to obtain will give us the opportunity to explain why you were
wrong to expect it, which might help you decide to retract your opinion.
If you refuse to answer the question, neither of those possibilities can
occur.
Similar explanations can be given why "is that really what you meant?",
"would that satisfy you?", and "what's the point?" are real, honest
questions, for which Keith would like to receive actual answers (I'd
like to hear them, too). If those explanations are not obvious, I (or
Keith) can provide them.
>> The standard documents the language. The documentation for a
>> particular implementation is likely to be useless without that
>> knowledge.
>>
>> The C standard says that the order of evaluation of function
>> arguments is unspecified. It also explains clearly what
>> "unspecified" means. Apparently that's not good enough for you,
>> but you haven't explained why.
>
> It doesn't explain what "unspecified" means other than undocumented
> implementation-defined. ...
The standard's description of "unspecified behavior" says neither
"undocumented" nor "implementation-defined" (and if it said both, that
would be a contradiction in terms, much like "negative value greater
than 10"). What it does say is:
"unspecified behavior
use of an unspecified value, or other behavior where this International
Standard provides two or more possibilities and imposes no further
requirements on which is chosen in any instance".
Key points: "this international standard", "two or more possibilities",
and "no further requirements on which is chosen". The behavior remains
"unspecified" as far as the C standard is concerned, even if some other
document (such as the POSIX standard or the documentation of a
particular implementation) does specify further requirements that narrow
it down. That's true even if they narrow it down to only a single
possibility.
> ... I have suggested already that these should
> be documented just like all the other implemenation-defined features.
Your wording ("all the other") incorrectly implies that "unspecified
behavior" is a subset of "implementation-defined". It's the other way
around: "implementation-defined behavior" is, specifically, the subset
of "unspecified behavior" for which documentation is required. What you
mean could more accurately be expressed by saying "all unspecified
behavior should also be implementation-defined".
> And I have stated repeatedly that I want everything documented.
Yes, and "David Kleinecke wants everything defined" is a good enough
argument only for David Kleinecke. If you want to convince anyone else
that this should be done (there is, of course, no requirement that you
care about convincing any one else), you need to give arguments that go
beyond expressing your preference for documentation - you need to give
arguments that explain a benefit from requiring documentation.
Keep in mind that many of the things that are unspecified, are
unspecified because a complete specification would be too long to write
in any reasonable amount of time, too long to read in any reasonable
amount of time, too long for the writer to be sure it's correct, and too
long for the reader to clearly understand what it means. Is there any
point in writing such a document?
I'm specifically thinking of the parts section 6.5 that leave
unspecified the order in which various things occur. A complete
specification of the order would require explaining exactly how all of
the optimizations that the compiler is capable of performing work, in
full detail, in all possible circumstances. The standard allows such
optimizations only when they don't change the behavior of strictly
conforming code. If you care about which order those things occur in,
you should write your code so that the order isn't unspecified (such a
re-write is always possible). In cases where you don't care about the
order, what benefit do you derive from having the implementation
document it? Note: mandating such documentation would have the effect of
either discouraging implementors from implementing hard-to-explain
optimizations, or from bothering to qualify as a fully conforming
implementation of C.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-13 09:02 -0700 |
| Message-ID | <bf532be7-e6e0-4871-a28d-36acc24ce3fa@googlegroups.com> |
| In reply to | #65432 |
On Sunday, July 12, 2015 at 11:13:20 AM UTC-7, James Kuyper wrote:
> On 07/12/2015 12:52 PM, David Kleinecke wrote:
> > On Saturday, July 11, 2015 at 5:15:58 PM UTC-7, Keith Thompson wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> >>> On Friday, July 10, 2015 at 12:11:53 PM UTC-7, Keith Thompson wrote:
> ...
> >>>> For the order to be truly *unpredictable*, it would have to use some
> >>>> high-quality random number generator to determine the order on each
> >>>> call. Is that really what you meant?
> >>>>
> >>>> In practice, the order is arbitrary, and may change depending on factors
> >>>> that are not at all obvious.
> >>>>
> >>>> I am perfectly satisfied with the standard's statement that the order is
> >>>> unspecified (and I'm glossing over the possibility that evaluation could
> >>>> be interleaved, since there are no sequence points between argument
> >>>> evaluations).
> >>>>
> >>>> If an implementation documented the order as "unpredictable", how would
> >>>> you benefit from that information?
> >>>>
> >>>> If gcc, for example, provided documentation that specified exactly how
> >>>> the order is determined (for a given release, target platform, and
> >>>> optimization level), how would you benefit from that information?
> >>>>
> >>>> If the documentation merely stated that the order is unspecified, would
> >>>> that satisfy you? If so, what's the point? That's exactly what the
> >>>> standard already says.
> >>>
> >>> You are assuming the standard is part of the documentation. I
> >>> suppose that is fair enough but it wasn't my assumption. Perhaps
> >>> I should add it. I would be much more willing to make that
> >>> assumption if the standard were better written.
> >>
> >> You've answered none of the questions I asked. Did you intend to?
> >
> > Most of your questions appear rhetorical to me. I don't answer
> > rhetorical questions.
>
> They weren't.
>
> For instance, "how would you benefit from that information?" Keith and I
> see no way to benefit from that information, and therefore no reason to
> require that it be documented. You insist that it should be documented,
> which implies that you might believe it could be beneficial to have it.
> If you're right about that, explaining the benefit to us would be
> helpful in convincing us (and many other people) that it should be
> required. If you're wrong, explaining the benefit that you incorrectly
> expect to obtain will give us the opportunity to explain why you were
> wrong to expect it, which might help you decide to retract your opinion.
> If you refuse to answer the question, neither of those possibilities can
> occur.
>
> Similar explanations can be given why "is that really what you meant?",
> "would that satisfy you?", and "what's the point?" are real, honest
> questions, for which Keith would like to receive actual answers (I'd
> like to hear them, too). If those explanations are not obvious, I (or
> Keith) can provide them.
>
> >> The standard documents the language. The documentation for a
> >> particular implementation is likely to be useless without that
> >> knowledge.
> >>
> >> The C standard says that the order of evaluation of function
> >> arguments is unspecified. It also explains clearly what
> >> "unspecified" means. Apparently that's not good enough for you,
> >> but you haven't explained why.
> >
> > It doesn't explain what "unspecified" means other than undocumented
> > implementation-defined. ...
>
> The standard's description of "unspecified behavior" says neither
> "undocumented" nor "implementation-defined" (and if it said both, that
> would be a contradiction in terms, much like "negative value greater
> than 10"). What it does say is:
>
> "unspecified behavior
> use of an unspecified value, or other behavior where this International
> Standard provides two or more possibilities and imposes no further
> requirements on which is chosen in any instance".
>
> Key points: "this international standard", "two or more possibilities",
> and "no further requirements on which is chosen". The behavior remains
> "unspecified" as far as the C standard is concerned, even if some other
> document (such as the POSIX standard or the documentation of a
> particular implementation) does specify further requirements that narrow
> it down. That's true even if they narrow it down to only a single
> possibility.
>
> > ... I have suggested already that these should
> > be documented just like all the other implemenation-defined features.
>
> Your wording ("all the other") incorrectly implies that "unspecified
> behavior" is a subset of "implementation-defined". It's the other way
> around: "implementation-defined behavior" is, specifically, the subset
> of "unspecified behavior" for which documentation is required. What you
> mean could more accurately be expressed by saying "all unspecified
> behavior should also be implementation-defined".
>
> > And I have stated repeatedly that I want everything documented.
>
> Yes, and "David Kleinecke wants everything defined" is a good enough
> argument only for David Kleinecke. If you want to convince anyone else
> that this should be done (there is, of course, no requirement that you
> care about convincing any one else), you need to give arguments that go
> beyond expressing your preference for documentation - you need to give
> arguments that explain a benefit from requiring documentation.
>
> Keep in mind that many of the things that are unspecified, are
> unspecified because a complete specification would be too long to write
> in any reasonable amount of time, too long to read in any reasonable
> amount of time, too long for the writer to be sure it's correct, and too
> long for the reader to clearly understand what it means. Is there any
> point in writing such a document?
>
> I'm specifically thinking of the parts section 6.5 that leave
> unspecified the order in which various things occur. A complete
> specification of the order would require explaining exactly how all of
> the optimizations that the compiler is capable of performing work, in
> full detail, in all possible circumstances. The standard allows such
> optimizations only when they don't change the behavior of strictly
> conforming code. If you care about which order those things occur in,
> you should write your code so that the order isn't unspecified (such a
> re-write is always possible). In cases where you don't care about the
> order, what benefit do you derive from having the implementation
> document it? Note: mandating such documentation would have the effect of
> either discouraging implementors from implementing hard-to-explain
> optimizations, or from bothering to qualify as a fully conforming
> implementation of C.
I dunno.
You make your attitude quite clear. I beg to disagree.
I want everything documented - no secrets. I don't think that that
desire needs much defending. It has been debated endlessly already.
One is either for it or against it.
Everything else is a corollary.
I imagine I understand why the standard is written the way it is and
I deplore the necessity for it. But I am willing to live with it
because many people follow it (usually at some distance). I am
trying to understand it.
In these discussions I have picked up a nuance that I never grasped
before - that the library headers might not be ".h" files like all
the other headers (which would certainly explain the otherwise
mysterious < .. > notation).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-13 13:18 -0400 |
| Message-ID | <55A3F2EB.5060502@verizon.net> |
| In reply to | #65493 |
On 07/13/2015 12:02 PM, David Kleinecke wrote: ... > I want everything documented - no secrets. I don't think that that > desire needs much defending. ... No, you're free to desire anything you want. You don't have to defend that. However, when you want someone else to do something to get you what you desire, you're going to have to give them a reason better than "I want this". Cash or favors can be useful reasons in other contexts, but in this context the only kind of reason you can usefully provide is an explanation why it would be a good idea for the standard to require this - of every single conforming implementation, no matter how difficult it is to provide the documentation (and in many cases, it would be very difficult), no matter how useless the resulting documentation would be (which would generally be the case). > ... It has been debated endlessly already. I haven't heard any debates - a debate involves both sides presenting arguments in support of their point of view, and you've provided no such arguments, just blind assertions that you think it should be done. > In these discussions I have picked up a nuance that I never grasped > before - that the library headers might not be ".h" files like all > the other headers (which would certainly explain the otherwise > mysterious < .. > notation). Here's another nuance: header files don't have to have a '.h' in them, either. That's just a very common convention, and many development tools recognize that convention, but it's not a requirement. I wouldn't hesitate to use a name that violated that convention if I thought I had a good reason to. I have, on occasion, had a good reason to #include a *.c file, but that is the only time that issue has ever come up. I've seen systems which recognized *.H and *.hpp as C++ - specific header file name extensions - but that's also just a convention (and not as widely recognized). Note that the relationship between the name provided in a #include directive and the location and name of the corresponding source file is implementation-defined (6.10.2p2). That gives an implementation the freedom to either enforce that naming convention, or prohibit it, among other more complicated possibilities.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-13 11:09 -0700 |
| Message-ID | <b6c46dda-cdfa-437f-95d6-81972600030e@googlegroups.com> |
| In reply to | #65498 |
On Monday, July 13, 2015 at 10:18:51 AM UTC-7, James Kuyper wrote: > On 07/13/2015 12:02 PM, David Kleinecke wrote: > ... > > I want everything documented - no secrets. I don't think that that > > desire needs much defending. ... > > No, you're free to desire anything you want. You don't have to defend > that. However, when you want someone else to do something to get you > what you desire, you're going to have to give them a reason better than > "I want this". Cash or favors can be useful reasons in other contexts, > but in this context the only kind of reason you can usefully provide is > an explanation why it would be a good idea for the standard to require > this - of every single conforming implementation, no matter how > difficult it is to provide the documentation (and in many cases, it > would be very difficult), no matter how useless the resulting > documentation would be (which would generally be the case). > > > ... It has been debated endlessly already. > > I haven't heard any debates - a debate involves both sides presenting > arguments in support of their point of view, and you've provided no such > arguments, just blind assertions that you think it should be done. > > > In these discussions I have picked up a nuance that I never grasped > > before - that the library headers might not be ".h" files like all > > the other headers (which would certainly explain the otherwise > > mysterious < .. > notation). > > Here's another nuance: header files don't have to have a '.h' in them, > either. That's just a very common convention, and many development tools > recognize that convention, but it's not a requirement. I wouldn't > hesitate to use a name that violated that convention if I thought I had > a good reason to. I have, on occasion, had a good reason to #include a > *.c file, but that is the only time that issue has ever come up. > I've seen systems which recognized *.H and *.hpp as C++ - specific > header file name extensions - but that's also just a convention (and not > as widely recognized). > > Note that the relationship between the name provided in a #include > directive and the location and name of the corresponding source file is > implementation-defined (6.10.2p2). That gives an implementation the > freedom to either enforce that naming convention, or prohibit it, among > other more complicated possibilities. You wont let me get away with nothing. Thanks - I think. As you noticed if we went the way I suggest all my non-header files would be .c files (or whatever). As nearly as I can tell I cannot make this extension (an end-of-header pre-processor directive) conforming because I cannot assume a pre-processor directive into a strictly-conforming program. Hum, a strictly conforming program uses only the explict features of the standard (including the library) but that says nothing about the use of non-library external functions. Phase 8 says "All external object and function references are resolved." leaving us to guess what "resolved" means. Assuming it means linked in I see no requirement that the external functions be conforming or even written in C. External object must be of a C nature but functions are only required to return a certain type.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-13 15:06 -0400 |
| Message-ID | <55A40C1E.5050706@verizon.net> |
| In reply to | #65504 |
On 07/13/2015 02:09 PM, David Kleinecke wrote: ... > As nearly as I can tell I cannot make this extension (an end-of-header > pre-processor directive) conforming because I cannot assume a > pre-processor directive into a strictly-conforming program. I would need a more complete description of what you want this extension to achieve before I could give you advice about that. If you've explained it before, I don't recognize it from that description. > Phase 8 says "All external object and function references are resolved." > leaving us to guess what "resolved" means. Assuming it means linked > in I see no requirement that the external functions be conforming or > even written in C. ... You're correct. The often aren't, particular the ones in the C standard library. > ... External object must be of a C nature but functions > are only required to return a certain type. External object references must refer to actual pieces of memory that can be interpreted as containing objects of the specified C types. Those pieces of memory might have been defined in languages far different from C, which might have used a radically different way of describing the type - but the actual format must be compatible. External function references are trickier. They must refer to the starting point of code that uses an interface compatible with that described by the function's C declaration. The function itself could be written in any language that supports such an interface - but that generally occurs only if it was specifically designed for C compatibility. C++ and the latest version of Fortran both have ways of specifying that the interface must be compatible with C. However, even a language with no special support for C might still allow the creation of some functions that are compatible with C, such as a function that takes no arguments and returns no value. Of course, assembly language can be used to write code compatible with any sufficiently-well-specified interface.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-14 08:14 -0700 |
| Message-ID | <670c2040-db68-4dc6-b278-4016684e90d8@googlegroups.com> |
| In reply to | #65511 |
On Monday, July 13, 2015 at 12:06:15 PM UTC-7, James Kuyper wrote:
> On 07/13/2015 02:09 PM, David Kleinecke wrote:
> ...
> > As nearly as I can tell I cannot make this extension (an end-of-header
> > pre-processor directive) conforming because I cannot assume a
> > pre-processor directive into a strictly-conforming program.
>
> I would need a more complete description of what you want this extension
> to achieve before I could give you advice about that. If you've
> explained it before, I don't recognize it from that description.
>
> > Phase 8 says "All external object and function references are resolved."
> > leaving us to guess what "resolved" means. Assuming it means linked
> > in I see no requirement that the external functions be conforming or
> > even written in C. ...
>
> You're correct. The often aren't, particular the ones in the C standard
> library.
>
> > ... External object must be of a C nature but functions
> > are only required to return a certain type.
>
> External object references must refer to actual pieces of memory that
> can be interpreted as containing objects of the specified C types. Those
> pieces of memory might have been defined in languages far different from
> C, which might have used a radically different way of describing the
> type - but the actual format must be compatible.
>
> External function references are trickier. They must refer to the
> starting point of code that uses an interface compatible with that
> described by the function's C declaration. The function itself could be
> written in any language that supports such an interface - but that
> generally occurs only if it was specifically designed for C
> compatibility. C++ and the latest version of Fortran both have ways of
> specifying that the interface must be compatible with C. However, even a
> language with no special support for C might still allow the creation of
> some functions that are compatible with C, such as a function that takes
> no arguments and returns no value. Of course, assembly language can be
> used to write code compatible with any sufficiently-well-specified
> interface.
The linking method I am familiar with links nothing but names. The old
terms are symref and symdef. A symref is an outward (external) link. It
consists of a name and an address where another potential address is
located. A symdef is also a pair of a name and and an address only here
the address is data. Linking consists of matching pairs of names and
putting the symdef address in the symref potential address. There also
is relocation which I have left out to keep things simple.
This kind of linking is blind to almost everything. All an external
function reference provides is an address where one is supposed to
jump. What is at the end of that jump depends.
This kind of linker pre-dates C and might be assumed by the Standard.
But as I have obeserved the Standard is vague where it might be precise
("All external object and function references are resolved." 5.1.1.2.8)
so I suspect they had something else in mind - but I am unable see what
that something else might be.
Of course, good practice is to have something at the end of a function
call makes sense.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-14 12:02 -0400 |
| Message-ID | <mo3boh$rd8$1@dont-email.me> |
| In reply to | #65548 |
On 07/14/2015 11:14 AM, David Kleinecke wrote:
...
> The linking method I am familiar with links nothing but names. The old
> terms are symref and symdef. A symref is an outward (external) link. It
> consists of a name and an address where another potential address is
> located. A symdef is also a pair of a name and and an address only here
> the address is data. Linking consists of matching pairs of names and
> putting the symdef address in the symref potential address. There also
> is relocation which I have left out to keep things simple.
>
> This kind of linking is blind to almost everything. All an external
> function reference provides is an address where one is supposed to
> jump. What is at the end of that jump depends.
Of course. "All declarations that refer to the same object or function
shall have compatible type; otherwise, the behavior is undefined."
(6.2.7p2). Whenever you have a declaration of identifier with external
linkage in a given module that does not also contain a matching
definition, someone needs to make sure that there is a corresponding
definition in some other module, with a compatible type. When someone
provides a library, it's the library provider who's responsible for the
accuracy of the declarations in the corresponding header files.
Since the behavior is undefined if they aren't compatible, an
implementation of C has no obligation to identify such mis-matches, and
no obligation to minimize the damage that might be done by them.
Therefore, the type-blind kind of linking you've described is adequate
to meet the requirements of the C standard.
A given implementation of C includes not only the C compiler, but also
the C standard library, the standard headers, and the linker (which
means that it's a misnomer to use "implementation" as a synonym for
"compiler"). It's not uncommon to have implementations where the
compiler, library and linker were provided by three different vendors,
which means that talking about the "implementor" as if it were a single
entity is also sometimes misleading - but it is convenient shorthand.
It's the responsibility of the implementor to ensure that the compiler
interprets the declarations provided by the standard headers as
identifying types for each such identifier that are compatible with the
definitions provided by the standard library.
> This kind of linker pre-dates C and might be assumed by the Standard.
> But as I have obeserved the Standard is vague where it might be precise
> ("All external object and function references are resolved." 5.1.1.2.8)
> so I suspect they had something else in mind - but I am unable see what
> that something else might be.
I don't think so. What you've described is pretty much exactly what I
believe the standard requires to occur during that phase. What makes you
think that the committee had anything else in mind? Keep in mind that
the C committee is not a bunch of idiots who have no idea how things
actually work. A large fraction of them represent actual implementors,
including many of the most important ones - the rest are mostly highly
knowlegble users of real-world implementations. The standard's
description of linkage is supposed to be compatible with how most
real-world linkers actually work - and the committee believes that
they've succeeded in that goal.
Have you, by any chance, misunderstood the C standard as requiring that
implementations diagnose type mismatches? 6.2.7p2 says otherwise.
> Of course, good practice is to have something at the end of a function
> call makes sense.
"good practice" seems an inadequate description. Is it even possible to
get a working program unless that's the case?
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-13 12:03 -0700 |
| Message-ID | <ln4ml7nalh.fsf@kst-u.example.com> |
| In reply to | #65493 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Sunday, July 12, 2015 at 11:13:20 AM UTC-7, James Kuyper wrote:
[detailed questions snipped]
> I dunno.
>
> You make your attitude quite clear. I beg to disagree.
>
> I want everything documented - no secrets. I don't think that that
> desire needs much defending. It has been debated endlessly already.
> One is either for it or against it.
This has not been what I'd call a debate. You've repeated ad
nauseam that you want everything to be documented. Unless I've
missed something, you have said nothing to support your opinion,
even after being directly asked to do so multiple times, using
various concrete examples.
You have wasted my time. (Well, strictly speaking, I suppose I have.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-14 07:54 -0700 |
| Message-ID | <e8c9dfed-cfa9-4546-9234-47cea2f8f483@googlegroups.com> |
| In reply to | #65510 |
On Monday, July 13, 2015 at 12:04:05 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Sunday, July 12, 2015 at 11:13:20 AM UTC-7, James Kuyper wrote: > [detailed questions snipped] > > > I dunno. > > > > You make your attitude quite clear. I beg to disagree. > > > > I want everything documented - no secrets. I don't think that that > > desire needs much defending. It has been debated endlessly already. > > One is either for it or against it. > > This has not been what I'd call a debate. You've repeated ad > nauseam that you want everything to be documented. Unless I've > missed something, you have said nothing to support your opinion, > even after being directly asked to do so multiple times, using > various concrete examples. > > You have wasted my time. (Well, strictly speaking, I suppose I have.) I wasn't debating why I want everything documented. There is a diffuse literature out there discussing the need for documentation and not any one authoritative reference. I was discussing ways in which C could be better documented. I am not responsible for you misunderstanding. I have suggested/asked about this or that and you have always responded - why would you want to do that?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-14 11:16 -0400 |
| Message-ID | <mo392j$gdb$1@dont-email.me> |
| In reply to | #65546 |
On 07/14/2015 10:54 AM, David Kleinecke wrote: > On Monday, July 13, 2015 at 12:04:05 PM UTC-7, Keith Thompson wrote: ... >> This has not been what I'd call a debate. You've repeated ad >> nauseam that you want everything to be documented. Unless I've >> missed something, you have said nothing to support your opinion, >> even after being directly asked to do so multiple times, using >> various concrete examples. >> >> You have wasted my time. (Well, strictly speaking, I suppose I have.) > > I wasn't debating why I want everything documented. There is a > diffuse literature out there discussing the need for documentation And the best of that literature should identify appropriate limits on documentation: how to determine whether or not you've put too much time and effort into documenting something, what level of detail is worth documenting, when the documentation gets too overwhelming in volume to be usefully searchible, who needs what level of documentation, etc. On that last point, the amount of documentation needed by the designers of an implementation of C is much greater than the amount needed by users of that implementation. The former comes close to what you're asking for, which is far greater than that latter. I'll grant you - actually providing excessive documentation is a very rare thing, because it requires a lot of hard work. However, requesting excessive documentation is a much more common failing, since all of the required work would have to be done by someone other than the requester. At one point, when I was managing a grand total of 2.5 people, I was asked to create documentation for my group's procedures that had sufficient depth of detail, and sufficient breadth of scope, that it would take one person several months per year, every year, just to keep the documentation up-to-date. The standards for the content of that documentation were nominally flexible, but the lower limit on that flexibility was high enough that it was clearly intended for a group much larger than mine. The documentation we actually had already written up was much smaller, and more than adequate to our needs. > and not any one authoritative reference. I was discussing ways in > which C could be better documented. I am not responsible for you > misunderstanding. ... There was no misunderstanding - we were never under the delusion of thinking that you were debating that issue. We were criticizing you for failing to do so, for simply automatically assuming that documentation was so obviously necessary that you didn't need to provide a reason, not even when repeatedly asked to do so. > ... I have suggested/asked about this or that and you > have always responded - why would you want to do that? Which is always a reasonable question to ask when no reason is given for doing something that doesn't seem to need to be done. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-14 16:17 +0100 |
| Message-ID | <mo3949$gjr$1@dont-email.me> |
| In reply to | #65546 |
On 14/07/15 15:54, David Kleinecke wrote: <snip> > I wasn't debating why I want everything documented. Yes, I noticed that. > There is a > diffuse literature out there discussing the need for documentation > and not any one authoritative reference. I was discussing ways in > which C could be better documented. I am not responsible for you > misunderstanding. I have suggested/asked about this or that and you > have always responded - why would you want to do that? It's not an unreasonable question. Why *would* you want to do that? It's rather as if you'd asked why main can't return double. Although it is possible to reason about this in the abstract, it really helps things along if people knew /why/ you would want main to return double. This would assist them in addressing your real[1] concerns. You have not as yet advanced any reason for implementations being required to document behaviour that is currently unspecified beyond that of "I think they should", and that just isn't enough. Even if by some chance some implementer is reading this thread (and some implementers /do/ read comp.lang.c), he or she is hardly going to say "gosh, David Kleinecke thinks I should document my implementation's unspecified behaviour - I'd better get right onto that" unless you've advanced some very compelling reasons as to why it's a good idea. This you have not yet done. Once people know /why/ you want this damn silly thing, maybe they'll be able to show you some strategy for fixing the problem other than in this damn silly way. [1] Sorry. I only noticed this afterwards. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-14 09:16 -0700 |
| Message-ID | <7be04ed7-d12b-41a5-9d9f-7c70b20936ea@googlegroups.com> |
| In reply to | #65550 |
On Tuesday, July 14, 2015 at 8:18:06 AM UTC-7, Richard Heathfield wrote: > On 14/07/15 15:54, David Kleinecke wrote: > > <snip> > > > I wasn't debating why I want everything documented. > > Yes, I noticed that. > > > There is a > > diffuse literature out there discussing the need for documentation > > and not any one authoritative reference. I was discussing ways in > > which C could be better documented. I am not responsible for you > > misunderstanding. I have suggested/asked about this or that and you > > have always responded - why would you want to do that? > > It's not an unreasonable question. Why *would* you want to do that? It's > rather as if you'd asked why main can't return double. Although it is > possible to reason about this in the abstract, it really helps things > along if people knew /why/ you would want main to return double. This > would assist them in addressing your real[1] concerns. > > You have not as yet advanced any reason for implementations being > required to document behaviour that is currently unspecified beyond that > of "I think they should", and that just isn't enough. Even if by some > chance some implementer is reading this thread (and some implementers > /do/ read comp.lang.c), he or she is hardly going to say "gosh, David > Kleinecke thinks I should document my implementation's unspecified > behaviour - I'd better get right onto that" unless you've advanced some > very compelling reasons as to why it's a good idea. This you have not > yet done. Once people know /why/ you want this damn silly thing, maybe > they'll be able to show you some strategy for fixing the problem other > than in this damn silly way. > > [1] Sorry. I only noticed this afterwards. OK. I admit that it never occurred to me that anyone would object to better documentation as a goal. Actually my real goal is to make C programs more readable. Metaphorically the language standard is the grammar of the language in which the program is written. So to reach my goal I want the grammar to be well understood.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-14 12:29 -0400 |
| Message-ID | <mo3dak$1ua$1@dont-email.me> |
| In reply to | #65560 |
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. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-14 14:57 -0400 |
| Message-ID | <mo3m0b$4kn$1@dont-email.me> |
| In reply to | #65564 |
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. 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. 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. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-07-14 13:12 -0700 |
| Message-ID | <ff66173f-db8b-48cb-9e2a-a4ae321b3bb5@googlegroups.com> |
| In reply to | #65579 |
On Tuesday, 14 July 2015 21:57:50 UTC+3, 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. Compiler may perhaps order initialization of non-volatile static variables how it sees fit since observable behavior that the program describes will stay same. However doesn't initialization of static storage duration volatile qualified variables mean side effects? Perhaps it is said somewhere that initialization of those does not mean side effects. Otherwise it would be nice if standard said something about order of such side effects.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-14 16:30 -0400 |
| Message-ID | <mo3rf2$r48$1@dont-email.me> |
| In reply to | #65585 |
On 07/14/2015 04:12 PM, Öö Tiib wrote: ... > Compiler may perhaps order initialization of non-volatile static > variables how it sees fit since observable behavior that the > program describes will stay same. > > However doesn't initialization of static storage duration volatile > qualified variables mean side effects? Perhaps it is said somewhere > that initialization of those does not mean side effects. Otherwise > it would be nice if standard said something about order of such > side effects. "Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all _side effects_, ..." (5.1.2.3p2). The phrase "side effects" is italicized, and ISO convention indicating that this sentence is the official definition of that phrase. Notice that it is only accessing a volatile object that is relevant. "What constitutes an access to an object that has volatile-qualified type is implementation-defined." (6.7.3p7) Therefore, whether or not initialization of a volatile-qualified object with static storage duration counts as accessing it must be defined by the implementation. Even if an implementation did document the order of initialization of such objects, I'm not sure what use could be made of that information. Could you give an example? -- James Kuyper
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web