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 | 11 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 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-07-09 11:17 +0000 |
| Message-ID | <559e579e.5338921@news.xs4all.nl> |
| In reply to | #64938 |
David Kleinecke <dkleinecke@gmail.com> wrote: > On Wednesday, July 8, 2015 at 9:11:33 AM UTC-7, Keith Thompson wrote: > > > > If I define two objects with static storage duration, I do not > > know or care in which order they're initialized. I see no benefit, > > and some significant cost, in a requirement to document the order. > > > > Let's take another example. The order in which arguments in a > > function call are evaluated is unspecified. If I write: > > > > func(arg1, arg2, arg3); > > > > the three arguments may be evaluated in any of 6 orders. > > Actually this is documented. They may be evaluated in any order. This is documented as unspecified in the Standard, and Keith is subtly wrong: they may indeed be evaluated in _any_ order, including, where that is possible, in parallel; and the implementation _need not_ specify which order is chosen. In fact, it may choose a different order for each invocation of this function, depending on context; and there is no reason for the C programmer to worry about which order it does choose. All you need to know is that the _result_ is as it should be. > We are having trouble with the word "unspecified". No, _you_ are having trouble with the word "unspecified", as well as with the words "undefined" and "implementation-defined". The rest of us do not have that trouble, and neither does the Standard. Richard
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-08 10:37 -0700 |
| Message-ID | <6289bbbb-e9a0-4e98-8352-e2f9795a1e31@googlegroups.com> |
| In reply to | #64918 |
On Wednesday, July 8, 2015 at 9:11:33 AM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > > > In the same way (see my final paragraph) I think the standard should > > require the form of the compiler output and other suchlike matters to > > be documented. I don't care how they are done - but they should be > > documented. > > You're just repeating your original assertion. You say, repeatedly, > that the behavior *should* be documented. You haven't explained > *why* it should be documented, or shown any benefit from such > a requirement. > > Any information that's actually relevant to programmers probably > already is documented, whether the standard requires it or not. > If your compiler fails to document something that you actually need > to know, complain to your compiler vendor. > > ... > > Compiler vendors are already free to document anything they like *if > they choose to*. Nobody is going to produce documentation for > irrelevant choices because you thinkÿ they "should". > > Again, what benefit would such a requirement have? (If you can answer > that without using the word "should", I'll be impressed.) Documentation can be written for several different reasons. One form instructs a potential user in how to use the compiler. A part of this documentation describes what the characteristics of the compiler are to allow a potential user to decide whether or not to use the program. For example, "This is a C compiler". The question seems to be about how much information must be supplied to allow a potential user to make an intellegent decsiion.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2015-07-08 10:51 -0700 |
| Message-ID | <3e870d57-2d23-4488-8c27-93c3fb5dccb0@googlegroups.com> |
| In reply to | #64941 |
On Wednesday, July 8, 2015 at 12:37:56 PM UTC-5, David Kleinecke wrote: > On Wednesday, July 8, 2015 at 9:11:33 AM UTC-7, Keith Thompson wrote: > > David Kleinecke <dkleinecke@gmail.com> writes: > > > > > > In the same way (see my final paragraph) I think the standard should > > > require the form of the compiler output and other suchlike matters to > > > be documented. I don't care how they are done - but they should be > > > documented. > > > > You're just repeating your original assertion. You say, repeatedly, > > that the behavior *should* be documented. You haven't explained > > *why* it should be documented, or shown any benefit from such > > a requirement. > > > > Any information that's actually relevant to programmers probably > > already is documented, whether the standard requires it or not. > > If your compiler fails to document something that you actually need > > to know, complain to your compiler vendor. > > > > ... > > > > Compiler vendors are already free to document anything they like *if > > they choose to*. Nobody is going to produce documentation for > > irrelevant choices because you thinkÿ they "should". > > > > Again, what benefit would such a requirement have? (If you can answer > > that without using the word "should", I'll be impressed.) > > Documentation can be written for several different reasons. One form > instructs a potential user in how to use the compiler. A part of this > documentation describes what the characteristics of the compiler are > to allow a potential user to decide whether or not to use the program. > For example, "This is a C compiler". The question seems to be about > how much information must be supplied to allow a potential user to > make an intellegent decsiion. An intelligent decision about *what*? What situation have you run into where the order of initialization of static objects changed the behavior or performance of your code? What potential issues do you see?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-08 14:14 -0400 |
| Message-ID | <559D687C.60904@verizon.net> |
| In reply to | #64941 |
On 07/08/2015 01:37 PM, David Kleinecke wrote: > On Wednesday, July 8, 2015 at 9:11:33 AM UTC-7, Keith Thompson wrote: ... >> You're just repeating your original assertion. You say, repeatedly, >> that the behavior *should* be documented. You haven't explained >> *why* it should be documented, or shown any benefit from such >> a requirement. >> >> Any information that's actually relevant to programmers probably >> already is documented, whether the standard requires it or not. >> If your compiler fails to document something that you actually need >> to know, complain to your compiler vendor. >> >> ... >> >> Compiler vendors are already free to document anything they like *if >> they choose to*. Nobody is going to produce documentation for >> irrelevant choices because you thinkÿ they "should". >> >> Again, what benefit would such a requirement have? (If you can answer >> that without using the word "should", I'll be impressed.) > > Documentation can be written for several different reasons. One form > instructs a potential user in how to use the compiler. A part of this > documentation describes what the characteristics of the compiler are > to allow a potential user to decide whether or not to use the program. > For example, "This is a C compiler". The question seems to be about > how much information must be supplied to allow a potential user to > make an intellegent decsiion. As a general rule, when the behavior is unspecified and not implementation-defined, that is because all the information needed by a potential user to make an intelligent decision is the fact that it is unspecified. All you need to do is write your code to cope with all of the permitted options, which is usually not spectacularly difficult. In almost every case, that list of permitted options is at least implied by the standard, if not explicitly provided. Note that the fact that something is unspecified by the standard doesn't prohibit a particular implementation from specifying the behavior itself; it may even actually be documented. Code targeting that particular implementation need only cope with the choice specified by that implementation's documentation. For instance, if an implementation documents that identical string literals are merged, code targeting that implementation is allowed to assume that "Hello" == "Hello", something not guaranteed by the standard.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-08 12:19 -0700 |
| Message-ID | <ln8uaqa256.fsf@kst-u.example.com> |
| In reply to | #64941 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Wednesday, July 8, 2015 at 9:11:33 AM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> >
>> > In the same way (see my final paragraph) I think the standard should
>> > require the form of the compiler output and other suchlike matters to
>> > be documented. I don't care how they are done - but they should be
>> > documented.
>>
>> You're just repeating your original assertion. You say, repeatedly,
>> that the behavior *should* be documented. You haven't explained
>> *why* it should be documented, or shown any benefit from such
>> a requirement.
>>
>> Any information that's actually relevant to programmers probably
>> already is documented, whether the standard requires it or not.
>> If your compiler fails to document something that you actually need
>> to know, complain to your compiler vendor.
>>
>> ...
>>
>> Compiler vendors are already free to document anything they like *if
>> they choose to*. Nobody is going to produce documentation for
>> irrelevant choices because you thinkÿ they "should".
>>
>> Again, what benefit would such a requirement have? (If you can answer
>> that without using the word "should", I'll be impressed.)
>
> Documentation can be written for several different reasons. One form
> instructs a potential user in how to use the compiler. A part of this
> documentation describes what the characteristics of the compiler are
> to allow a potential user to decide whether or not to use the program.
> For example, "This is a C compiler". The question seems to be about
> how much information must be supplied to allow a potential user to
> make an intellegent decsiion.
Each implementation can document whatever it likes, whether the standard
requires it or not. You can certainly take that into account when
deciding whether to use an implementation.
In some cases (such as the order of initialization of static objects),
the *lack* of documentation might slightly incline me in favor of an
implementation, since it means the implementers aren't wasting their
time documenting something that is of no use to me. (Emphasis on
"slightly".)
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-08 12:14 -0400 |
| Message-ID | <559D4C4F.5090602@verizon.net> |
| In reply to | #64914 |
On 07/08/2015 11:47 AM, David Kleinecke wrote: > On Tuesday, July 7, 2015 at 3:35:04 PM UTC-7, Keith Thompson wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: ... >>> proper. I think the standard should make the interface to the loader >>> (if any) explicit. ... > All I'm asking of the standard is that it ask implementators to > document what they are doing. ... Then you worded your explanation incorrectly. To say that "the standard should make [it] explicit" means that the standard itself must specify the interface. The meaning you intended would be properly conveyed by saying: "the standard should make the interface to the loader implementation-defined". That wouldn't be too bad an idea. I would expect most compiler implementations to document the interface by cross-referencing some other document, rather than by providing the details themselves, and I believe that's the right way to handle such things, since the interface details are properly associated with the loader than with the compiler.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-08 10:40 -0700 |
| Message-ID | <0753b11d-66eb-4c9a-ae7c-63e580bd896a@googlegroups.com> |
| In reply to | #64919 |
On Wednesday, July 8, 2015 at 9:14:17 AM UTC-7, James Kuyper wrote: > On 07/08/2015 11:47 AM, David Kleinecke wrote: > > On Tuesday, July 7, 2015 at 3:35:04 PM UTC-7, Keith Thompson wrote: > >> David Kleinecke <dkleinecke@gmail.com> writes: > ... > >>> proper. I think the standard should make the interface to the loader > >>> (if any) explicit. > ... > > All I'm asking of the standard is that it ask implementators to > > document what they are doing. ... > > Then you worded your explanation incorrectly. To say that "the standard > should make [it] explicit" means that the standard itself must specify > the interface. The meaning you intended would be properly conveyed by > saying: "the standard should make the interface to the loader > implementation-defined". > > That wouldn't be too bad an idea. I would expect most compiler > implementations to document the interface by cross-referencing some > other document, rather than by providing the details themselves, and I > believe that's the right way to handle such things, since the interface > details are properly associated with the loader than with the compiler. Many, perhaps most, C programs are embedded and do not interface with a loader. People need to know just what they do interface with.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-08 14:29 -0400 |
| Message-ID | <559D6BED.4070302@verizon.net> |
| In reply to | #64942 |
On 07/08/2015 01:40 PM, David Kleinecke wrote: > On Wednesday, July 8, 2015 at 9:14:17 AM UTC-7, James Kuyper wrote: ... >> Then you worded your explanation incorrectly. To say that "the standard >> should make [it] explicit" means that the standard itself must specify >> the interface. The meaning you intended would be properly conveyed by >> saying: "the standard should make the interface to the loader >> implementation-defined". >> >> That wouldn't be too bad an idea. I would expect most compiler >> implementations to document the interface by cross-referencing some >> other document, rather than by providing the details themselves, and I >> believe that's the right way to handle such things, since the interface >> details are properly associated with the loader than with the compiler. > > Many, perhaps most, C programs are embedded and do not interface with > a loader. People need to know just what they do interface with. Well, that makes your suggestion even more problematic, since your suggestion implies that there is a loader. You can't mandate documentation of the loader interface without implicitly mandating the existence of a loader that is separate from the rest of the implementation. That, in turn, requires specification of what precisely a loader is. I didn't bother asking you that before, but would you care to provide a specification of what a "loader" is that is sufficiently precise to be usable for this purpose? The C standard deliberately leaves the detailed structure of a C implementation unspecified. Whether it's a single program, or three separate programs handling pre-processing, compilation, and linkage, or 8 different programs, one for each translation phase - that's all unspecified by the C standard, to give implementors the freedom to implement the language in any way that's convenient on a given platform.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-07-09 11:20 +0000 |
| Message-ID | <559e58d3.5648328@news.xs4all.nl> |
| In reply to | #64954 |
James Kuyper <jameskuyper@verizon.net> wrote: > The C standard deliberately leaves the detailed structure of a C > implementation unspecified. Whether it's a single program, or three > separate programs handling pre-processing, compilation, and linkage, or > 8 different programs, one for each translation phase - that's all > unspecified by the C standard, to give implementors the freedom to > implement the language in any way that's convenient on a given platform. The C Standard doesn't even forbid an interpreter. Richard
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-07-09 02:30 -0500 |
| Message-ID | <gm8spad4ekfsqet4uu4f9jpsfpc0h8ieju@4ax.com> |
| In reply to | #64914 |
On Wed, 8 Jul 2015 08:47:42 -0700 (PDT), David Kleinecke <dkleinecke@gmail.com> wrote: >On Tuesday, July 7, 2015 at 3:35:04 PM UTC-7, Keith Thompson wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: >> > Unspecified Behaviors in C90 - part 1 >> > >> > Appendix G.1 to the 1990 ISO Standard lists 22 unspecified behaviors >> > recognized by the standard. These behaviors are of interest because >> > an implementation of C is not required to document them. >> > >> > 1. The manner and timing of static initialization (5.1.2) >> > >> > 5.1.2 says "All objects in static storage shall be initialized (set to >> > their initial values) before program startup. The manner and timing of >> > such initialization are otherwise unspecified. There are otherwise no >> > reserved external identifiers." >> > >> > "Static" appears to refer to the storage durations of objects >> > (6.1.2.4) where two durations are defined - static and >> > automatic. >> >> C90 neglected to mention "allocated" storage duration, for objects >> allocated by malloc() and friends. C99 added it. C11 adds thread >> storage duration, for objects that exist during the execution of the >> thread that created them. >> >> > Static duration applies to all objects declared outside of >> > functions (and inside if specifically called static). The program >> > startup is a call to a function (main if hosted). It appears that the >> > standard considers this initialization a function (probably automatic) >> > of the loader (if any) and therefore not a matter for the program >> > proper. I think the standard should make the interface to the loader >> > (if any) explicit. >> >> Why? How would this interface be defined, and how would programmers >> benefit from such a definition? >> >> If I write: >> >> static int x = 10; >> static int y = 20; >> >> the standard says that x and y are initialized to 10 and 20, >> respectively, some time before entry to the main function (or, for a >> freestanding implementation, to the implementation-defined entry point). >> The way in which these initializations happen, and the order in which >> they occur, is unspecified. >> >> Initializers for static objects must be constant expressions, so side >> effects are not an issue. >> >> It has never occurred to me to care about the order in which these >> initializations happen. They're done before any of my code executes. >> Do you really want to require all implementations to document this >> irrelevant detail? >> >> > It appears I favor a standard that reaches all the way back to a >> > program's form in permanent storage. That opens a can of worms. > >All I'm asking of the standard is that it ask implementators to >document what they are doing. Consider an embedded program that is >hardwired into a device. They should document where the initialized >data is - it might be in the program and accessed there. It might be >in the program and transferred to active memory before startup. I am >no expert on embedded systems. But what it must be should be >documented. > >In the same way (see my final paragraph) I think the standard should >require the form of the compiler output and other suchlike matters to >be documented. I don't care how they are done - but they should be >documented. Does that include things like the object module format? What about for systems supporting LTCG, where the "object" module format is usually a dump of the compiler's internal parse tree or something like that. And in that case documenting it would probably be so hard that LTCG would have to be a non-conforming feature, which is a bit absurd.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-07 22:30 -0400 |
| Message-ID | <mni1u0$cav$1@dont-email.me> |
| In reply to | #64878 |
On 07/07/2015 05:44 PM, David Kleinecke wrote: > Unspecified Behaviors in C90 - part 1 > > Appendix G.1 to the 1990 ISO Standard lists 22 unspecified behaviors > recognized by the standard. These behaviors are of interest because an implementation of C is not required to document them. > > 1. The manner and timing of static initialization (5.1.2) > > 5.1.2 says "All objects in static storage shall be initialized (set to > their initial values) before program startup. The manner and timing of > such initialization are otherwise unspecified. There are otherwise no > reserved external identifiers." > > "Static" appears to refer to the storage durations of objects (6.1.2.4) > where two durations are defined - static and automatic. Static duration > applies to all objects declared outside of functions (and inside if > specifically called static). The program startup is a call to a > function (main if hosted). It appears that the standard considers this initialization a function (probably automatic) of the loader (if any) > and therefore not a matter for the program proper. I think the standard > should make the interface to the loader (if any) explicit. Why? What benefit do you see in that? Can you show me a simple program that demonstrates the benefit? One of the key goals of the C language is easy implementability on a wide variety of platforms. A lot of the undefined, implementation-defined and unspecified behavior in C exists precisely to make that easy. As a result, an implementation of C is quite often one of the first applications written for any new platform. Implementations of other higher-level languages are often written in C, for precisely this reason. Many platforms come with their own linker, and all an implementation of C for a given platform has to do is comply with the platform-specific interface for that linker. Your suggestion would require that if the linker on a given platform doesn't happen to conform to the interface specified by the C standard (and most won't - simply because there is a large variety of mutually incompatible existing interfaces) an implementor of C targeting that platform must waste time and money creating it's own linker. I say again - what benefit do you think is achieved that justifies that cost? -- James Kuyper
[toc] | [prev] | [standalone]
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
Back to top | Article view | comp.lang.c
csiph-web