Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #64310 > unrolled thread
| Started by | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| First post | 2015-06-27 11:19 -0700 |
| Last post | 2015-06-28 11:57 +0200 |
| Articles | 20 on this page of 68 — 15 participants |
Back to article view | Back to comp.lang.c
More physical source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-27 11:19 -0700
Re: More physical source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-27 11:54 -0700
Re: More physical source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-27 21:20 +0100
Re: More physical source files Bartc <bc@freeuk.com> - 2015-06-27 20:24 +0100
Re: More physical source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-29 07:14 -0700
Re: More physical source files Keith Thompson <kst-u@mib.org> - 2015-06-29 08:16 -0700
Re: More physical source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-30 08:24 -0700
Re: More physical source files Robert Wessel <robertwessel2@yahoo.com> - 2015-06-30 12:15 -0500
Re: More physical source files Keith Thompson <kst-u@mib.org> - 2015-06-30 15:14 -0700
Re: More physical source files David Kleinecke <dkleinecke@gmail.com> - 2015-07-01 08:38 -0700
Re: More physical source files glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-01 16:43 +0000
Re: More physical source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-01 18:52 +0100
Re: More physical source files Keith Thompson <kst-u@mib.org> - 2015-07-01 11:21 -0700
Re: More physical source files glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-01 18:36 +0000
Re: More physical source files Richard Damon <Richard@Damon-Family.org> - 2015-07-01 22:33 -0400
Re: More physical source files glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-02 19:11 +0000
Re: More physical source files Keith Thompson <kst-u@mib.org> - 2015-07-01 11:08 -0700
Re: More physical source files Richard Damon <Richard@Damon-Family.org> - 2015-07-01 22:30 -0400
Re: More physical source files David Kleinecke <dkleinecke@gmail.com> - 2015-07-02 08:29 -0700
Re: More physical source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-02 17:56 +0100
Re: More physical source files James Kuyper <jameskuyper@verizon.net> - 2015-07-02 13:21 -0400
Re: More physical source files David Kleinecke <dkleinecke@gmail.com> - 2015-07-03 08:54 -0700
Re: More physical source files James Kuyper <jameskuyper@verizon.net> - 2015-07-04 12:23 -0400
Re: More physical source files Martin Shobe <martin.shobe@yahoo.com> - 2015-07-04 11:36 -0500
Re: More physical source files Keith Thompson <kst-u@mib.org> - 2015-07-02 16:42 -0700
Re: More physical source files David Kleinecke <dkleinecke@gmail.com> - 2015-07-03 08:54 -0700
Re: More physical source files Keith Thompson <kst-u@mib.org> - 2015-07-03 10:05 -0700
Re: More physical source files glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-03 21:57 +0000
Re: More physical source files James Kuyper <jameskuyper@verizon.net> - 2015-07-04 00:30 -0400
Re: More physical source files David Kleinecke <dkleinecke@gmail.com> - 2015-07-04 08:08 -0700
Re: More physical source files Richard Damon <Richard@Damon-Family.org> - 2015-07-04 12:21 -0400
Re: More physical source files David Kleinecke <dkleinecke@gmail.com> - 2015-07-05 09:22 -0700
Re: More physical source files David Kleinecke <dkleinecke@gmail.com> - 2015-07-05 09:49 -0700
Re: More physical source files Keith Thompson <kst-u@mib.org> - 2015-07-05 18:16 -0700
Re: More physical source files David Kleinecke <dkleinecke@gmail.com> - 2015-07-06 08:37 -0700
Re: More physical source files James Kuyper <jameskuyper@verizon.net> - 2015-07-06 12:56 -0400
Re: More physical source files Keith Thompson <kst-u@mib.org> - 2015-07-06 11:59 -0700
Re: More physical source files James Kuyper <jameskuyper@verizon.net> - 2015-07-06 15:45 -0400
Re: More physical source files Keith Thompson <kst-u@mib.org> - 2015-07-06 13:14 -0700
Re: More physical source files Philip Lantz <prl@canterey.us> - 2015-07-07 01:10 -0700
Re: More physical source files David Kleinecke <dkleinecke@gmail.com> - 2015-07-07 08:00 -0700
Re: More physical source files David Kleinecke <dkleinecke@gmail.com> - 2015-07-07 07:55 -0700
Re: More physical source files James Kuyper <jameskuyper@verizon.net> - 2015-07-07 13:13 -0400
Re: More physical source files David Kleinecke <dkleinecke@gmail.com> - 2015-07-08 08:35 -0700
Re: More physical source files James Kuyper <jameskuyper@verizon.net> - 2015-07-08 12:31 -0400
Re: More physical source files David Kleinecke <dkleinecke@gmail.com> - 2015-07-09 08:50 -0700
Re: More physical source files Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 16:56 +0100
Re: More physical source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-09 13:31 -0700
Re: More physical source files Keith Thompson <kst-u@mib.org> - 2015-07-09 15:03 -0700
Re: More physical source files Ian Collins <ian-news@hotmail.com> - 2015-07-10 10:54 +1200
Re: More physical source files David Kleinecke <dkleinecke@gmail.com> - 2015-07-10 09:52 -0700
Re: More physical source files James Kuyper <jameskuyper@verizon.net> - 2015-07-09 14:32 -0400
Re: More physical source files James Kuyper <jameskuyper@verizon.net> - 2015-07-05 13:41 -0400
Re: More physical source files Richard Damon <Richard@Damon-Family.org> - 2015-07-05 14:17 -0400
Re: More physical source files Keith Thompson <kst-u@mib.org> - 2015-07-04 12:36 -0700
Re: More physical source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-04 15:19 -0700
Re: More physical source files Keith Thompson <kst-u@mib.org> - 2015-07-04 15:42 -0700
Re: More physical source files James Kuyper <jameskuyper@verizon.net> - 2015-07-04 19:04 -0400
Re: More physical source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-05 03:25 -0700
Re: More physical source files Keith Thompson <kst-u@mib.org> - 2015-07-05 09:18 -0700
Re: More physical source files James Kuyper <jameskuyper@verizon.net> - 2015-07-05 14:11 -0400
Re: More physical source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-05 13:41 -0700
Re: More physical source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 19:00 -0700
Re: More physical source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 18:57 -0700
Re: More physical source files James Kuyper <jameskuyper@verizon.net> - 2015-07-04 12:50 -0400
Re: More physical source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:39 -0700
Re: More physical source files Bartc <bc@freeuk.com> - 2015-06-29 17:20 +0100
Re: More physical source files Rosario19 <Ros@invalid.invalid> - 2015-06-28 11:57 +0200
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-02 13:21 -0400 |
| Message-ID | <559572FC.3030308@verizon.net> |
| In reply to | #64623 |
On Thursday, July 2, 2015 at 11:29:35 AM UTC-4, David Kleinecke wrote:
> On Wednesday, July 1, 2015 at 11:08:11 AM UTC-7, Keith Thompson wrote:
> > David Kleinecke <dkleinecke@gmail.com> writes:
> > > I gather that error correcting would be possible in a conforming
> > > compiler. It is strictly compiling where that is not possible.
> >
> > I don't know what you mean by "strictly compiling". There is
> > a concept of "strictly conforming", but it applies to programs,
> > not to compilers. A compiler (more precisely an implementation)
> > is either conforming or not. A program using an extension is not
> > strictly conforming, but it may be conforming ("conforming" is a
> > very loose criterion for programs).
>
> I garbled that. My bad. I meant a compiler that only accepts strictly
> conforming programs. Such compilers are not specifically mentioned in
> the standard but can be assume to exist. ...
It will make my writing easier if I have a name for the category you've
described above. While it was a misnomer on your part, the phrase
"strictly compiling" has not been given any other official meaning. I
hope you won't mind if I use it below to refer to an implementation that
only accepts strictly conforming programs.
I don't think it's reasonable to assume that any strictly compiling
implementations exist. A conforming implementation of C must accept all
strictly conforming programs. A strictly compiling implementation must
compile only strictly conforming programs. A strictly compiling
implementation that conformed to the C standard would, therefore, have
to perfectly distinguish strictly conforming programs from programs that
are not strictly conforming.
It can be shown that, in some cases, determining whether or not a
program is strictly conforming is equivalent to solving the halting
problem, a task that was long ago proven to be impossible. A compiler
must either conform to the C standard by compiling some programs that
are not strictly conforming, or qualify as strictly compiling by
rejecting some programs that are strictly conforming. No compiler can do
both. I doubt that there is any vendor, anywhere, who would consider
"strictly compiling" to be sufficiently important to sacrifice C
conformance. Most go in the opposite direction: C conformance is an
option that has to be actively selected. By default, they operate in a
non-conforming mode that supports a number of extensions that their
customers want to use.
The connection to the halting problem is simple: some C constructs have
behavior that is undefined only if some other piece of code with
particular characteristics has already been executed (double free()s,
for instance). Let the execution of one of the two constructs depend
upon whether or not a given subroutine ever returns. Then determining
whether the behavior of the program is undefined requires solving the
halting problem for that subroutine.
The connection to the halting problem is proven using code that can
trivially be fixed to avoid the undefined behavior: if the subroutine
does return, DON'T execute that line of code. However, it's just proof
of the more general principle: it can be arbitrarily hard to determine
whether or not any particular program is strictly conforming.
> ... Any program that compiles on
> one is, per the standard, portable to any conforming compiler without
> change. I think this is what gcc means by "pedantic".
No, it is not. What "pedantic" does is guarantee that gcc fully conforms
to the specified version of the C (or C++) standard. Without -pedantic,
-ansi only enables all features of C89 - it doesn't enable the
mandatory diagnostics for some gnu features that C89 considered to be
syntax errors or constraint violations.
The -pedantic option doesn't guarantee that all programs accepted by gcc
are strictly conforming. For the reasons given above, like all
real-world compilers, there are many ways for a program to have
undefined behavior that gcc is incapable of detecting.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-03 08:54 -0700 |
| Message-ID | <36cf5a67-6589-42aa-9fae-26c59aa1a061@googlegroups.com> |
| In reply to | #64625 |
On Thursday, July 2, 2015 at 10:21:10 AM UTC-7, James Kuyper wrote:
> On Thursday, July 2, 2015 at 11:29:35 AM UTC-4, David Kleinecke wrote:
> > On Wednesday, July 1, 2015 at 11:08:11 AM UTC-7, Keith Thompson wrote:
> > > David Kleinecke <dkleinecke@gmail.com> writes:
> > > > I gather that error correcting would be possible in a conforming
> > > > compiler. It is strictly compiling where that is not possible.
> > >
> > > I don't know what you mean by "strictly compiling". There is
> > > a concept of "strictly conforming", but it applies to programs,
> > > not to compilers. A compiler (more precisely an implementation)
> > > is either conforming or not. A program using an extension is not
> > > strictly conforming, but it may be conforming ("conforming" is a
> > > very loose criterion for programs).
> >
> > I garbled that. My bad. I meant a compiler that only accepts strictly
> > conforming programs. Such compilers are not specifically mentioned in
> > the standard but can be assume to exist. ...
>
> It will make my writing easier if I have a name for the category you've
> described above. While it was a misnomer on your part, the phrase
> "strictly compiling" has not been given any other official meaning. I
> hope you won't mind if I use it below to refer to an implementation that
> only accepts strictly conforming programs.
>
> I don't think it's reasonable to assume that any strictly compiling
> implementations exist. A conforming implementation of C must accept all
> strictly conforming programs. A strictly compiling implementation must
> compile only strictly conforming programs. A strictly compiling
> implementation that conformed to the C standard would, therefore, have
> to perfectly distinguish strictly conforming programs from programs that
> are not strictly conforming.
> It can be shown that, in some cases, determining whether or not a
> program is strictly conforming is equivalent to solving the halting
> problem, a task that was long ago proven to be impossible. A compiler
> must either conform to the C standard by compiling some programs that
> are not strictly conforming, or qualify as strictly compiling by
> rejecting some programs that are strictly conforming. No compiler can do
> both. I doubt that there is any vendor, anywhere, who would consider
> "strictly compiling" to be sufficiently important to sacrifice C
> conformance. Most go in the opposite direction: C conformance is an
> option that has to be actively selected. By default, they operate in a
> non-conforming mode that supports a number of extensions that their
> customers want to use.
>
> The connection to the halting problem is simple: some C constructs have
> behavior that is undefined only if some other piece of code with
> particular characteristics has already been executed (double free()s,
> for instance). Let the execution of one of the two constructs depend
> upon whether or not a given subroutine ever returns. Then determining
> whether the behavior of the program is undefined requires solving the
> halting problem for that subroutine.
> The connection to the halting problem is proven using code that can
> trivially be fixed to avoid the undefined behavior: if the subroutine
> does return, DON'T execute that line of code. However, it's just proof
> of the more general principle: it can be arbitrarily hard to determine
> whether or not any particular program is strictly conforming.
>
> > ... Any program that compiles on
> > one is, per the standard, portable to any conforming compiler without
> > change. I think this is what gcc means by "pedantic".
>
> No, it is not. What "pedantic" does is guarantee that gcc fully conforms
> to the specified version of the C (or C++) standard. Without -pedantic,
> -ansi only enables all features of C89 - it doesn't enable the
> mandatory diagnostics for some gnu features that C89 considered to be
> syntax errors or constraint violations.
> The -pedantic option doesn't guarantee that all programs accepted by gcc
> are strictly conforming. For the reasons given above, like all
> real-world compilers, there are many ways for a program to have
> undefined behavior that gcc is incapable of detecting.
I was wrong about "pedantic" - but it was only a guess.
As I have comment elsewhere I see a problem in what "unspecified"
means. But surely you are right about undecidability under one
interpretation of "unspecified".
Assuming you conclusion, doesn't it follow that there is no test
program that will tell us whether a given program is strictly
conforming. And therefore no algorithm for determining whether a
compiler is conforming?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-04 12:23 -0400 |
| Message-ID | <55980890.5000104@verizon.net> |
| In reply to | #64625 |
On Friday, July 3, 2015 at 11:54:33 AM UTC-4, David Kleinecke wrote: > On Thursday, July 2, 2015 at 10:21:10 AM UTC-7, James Kuyper wrote: ... > > No, it is not. What "pedantic" does is guarantee that gcc fully conforms > > to the specified version of the C (or C++) standard. Without -pedantic, > > -ansi only enables all features of C89 - it doesn't enable the > > mandatory diagnostics for some gnu features that C89 considered to be > > syntax errors or constraint violations. > > The -pedantic option doesn't guarantee that all programs accepted by gcc > > are strictly conforming. For the reasons given above, like all > > real-world compilers, there are many ways for a program to have > > undefined behavior that gcc is incapable of detecting. > > I was wrong about "pedantic" - but it was only a guess. The problem is not so much "-pedantic", but about what you thought it meant. Your guess about what it meant was something it couldn't possibly mean, for reasons that have nothing to do with the name of the option. > As I have comment elsewhere I see a problem in what "unspecified" > means. But surely you are right about undecidability under one > interpretation of "unspecified". Actually, the meaning of "unspecified" is irrelevant to my argument - the key issue is "undefined behavior". Furthermore, it's not the meaning of "undefined behavior" that is relevant, but the specific kinds of things that the C standard says make the behavior of a program undefined. The key feature is that, in some cases, the behavior is undefined if two different pieces of code are both executed, even if those pieces of code are widely separated both in time and in their physical location in the code. There may be cases where the behavior is merely "unspecified" when two widely separated pieces of code are executed, and if that were the case, it would be sufficient in itself to make it impossible to determine whether a piece of code is strictly conforming. However, examples where the behavior is undefined come to my mind much more readily. > Assuming you conclusion, doesn't it follow that there is no test > program that will tell us whether a given program is strictly > conforming. ... Of course. Such a test program would necessarily be able to solve the halting problem, which has been proven to be impossible. If such a test program could exist, it could be incorporated into a "strictly compiling" implementation, to allow it to also be fully conforming. > ... And therefore no algorithm for determining whether a > compiler is conforming? Of course there's no such algorithm. Treated as a black box, a compiler is conforming only if it handles every possible program, when executed with every possible input, in accordance with the requirements specified by the standard. The only way to prove that a black box compiler is conforming would be to pass it such a doubly-infinite set of test cases. Note also that strictly conforming programs can contain infinite loops, so infinitely many of the test cases will each take infinitely long to complete. Failing any one of these test cases renders the implementation non-conforming, no matter how many other test cases it passes. Incorrectly translating a program that contains an infinite loop renders the implementation non-conforming, even if the loop must keep running for a billion years before the incorrect translation produces observable effects. If you don't treat an implementation as a black box, but actually examine the details of how it is designed, I can't come up with an argument that renders it impossible to determine that it's fully conforming. However, it is extraordinarily difficult to prove that even relatively simple programs are correct; and an implementation of C is likely to be anything but simple. The C standard is 683 pages long, and full conformance requires conforming to every requirement imposed by every sentence in the normative parts of that document. And those sentences are in English, not in some more formal specification language. I don't think it's even possible to prove that the standard is entirely self-consistent (it probably isn't - if I thought about it long enough, I could probably even give you a known example). If it isn't self-consistent, fully conforming with it would be impossible, so proving that an implementation is fully conforming would also be impossible. Whether code is "strictly conforming", and whether an implementation is "fully conforming" are things that, in the general case, can only be disproven by a finite example, they can't be proven. This is not particularly unusual; it's a trait shared by most useful statements about reality (for a particular definition of "useful").
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-07-04 11:36 -0500 |
| Message-ID | <mn91v8$1pi$1@dont-email.me> |
| In reply to | #64665 |
On 7/4/2015 11:23 AM, James Kuyper wrote: > On Friday, July 3, 2015 at 11:54:33 AM UTC-4, David Kleinecke wrote: >> On Thursday, July 2, 2015 at 10:21:10 AM UTC-7, James Kuyper wrote: > ... >>> No, it is not. What "pedantic" does is guarantee that gcc fully conforms >>> to the specified version of the C (or C++) standard. Without -pedantic, >>> -ansi only enables all features of C89 - it doesn't enable the >>> mandatory diagnostics for some gnu features that C89 considered to be >>> syntax errors or constraint violations. >>> The -pedantic option doesn't guarantee that all programs accepted by gcc >>> are strictly conforming. For the reasons given above, like all >>> real-world compilers, there are many ways for a program to have >>> undefined behavior that gcc is incapable of detecting. >> >> I was wrong about "pedantic" - but it was only a guess. > > The problem is not so much "-pedantic", but about what you thought it > meant. Your guess about what it meant was something it couldn't possibly > mean, for reasons that have nothing to do with the name of the option. > >> As I have comment elsewhere I see a problem in what "unspecified" >> means. But surely you are right about undecidability under one >> interpretation of "unspecified". > > Actually, the meaning of "unspecified" is irrelevant to my argument - > the key issue is "undefined behavior". Furthermore, it's not the meaning > of "undefined behavior" that is relevant, but the specific kinds of > things that the C standard says make the behavior of a program > undefined. The key feature is that, in some cases, the behavior is > undefined if two different pieces of code are both executed, even if > those pieces of code are widely separated both in time and in their > physical location in the code. There may be cases where the behavior is > merely "unspecified" when two widely separated pieces of code are > executed, and if that were the case, it would be sufficient in itself to > make it impossible to determine whether a piece of code is strictly > conforming. However, examples where the behavior is undefined come to my > mind much more readily. > >> Assuming you conclusion, doesn't it follow that there is no test >> program that will tell us whether a given program is strictly >> conforming. ... > > Of course. Such a test program would necessarily be able to solve the > halting problem, which has been proven to be impossible. If such a test > program could exist, it could be incorporated into a "strictly > compiling" implementation, to allow it to also be fully conforming. > >> ... And therefore no algorithm for determining whether a >> compiler is conforming? > > Of course there's no such algorithm. Treated as a black box, a compiler > is conforming only if it handles every possible program, when executed > with every possible input, in accordance with the requirements specified > by the standard. The only way to prove that a black box compiler is > conforming would be to pass it such a doubly-infinite set of test cases. > Note also that strictly conforming programs can contain infinite loops, > so infinitely many of the test cases will each take infinitely long to > complete. Failing any one of these test cases renders the implementation > non-conforming, no matter how many other test cases it passes. > Incorrectly translating a program that contains an infinite loop renders > the implementation non-conforming, even if the loop must keep running > for a billion years before the incorrect translation produces observable > effects. > > If you don't treat an implementation as a black box, but actually > examine the details of how it is designed, I can't come up with an > argument that renders it impossible to determine that it's fully > conforming. He asked for an algorithm to determine it. You can use Rice's theorem to show that there is no such algorithm. In any particular case, you might be able to prove that it conforms. I strongly suspect that such a proof would be extremely difficult. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-02 16:42 -0700 |
| Message-ID | <lnegkq160c.fsf@kst-u.example.com> |
| In reply to | #64620 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Wednesday, July 1, 2015 at 11:08:11 AM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > I gather that error correcting would be possible in a conforming
>> > compiler. It is strictly compiling where that is not possible.
>>
>> I don't know what you mean by "strictly compiling". There is
>> a concept of "strictly conforming", but it applies to programs,
>> not to compilers. A compiler (more precisely an implementation)
>> is either conforming or not. A program using an extension is not
>> strictly conforming, but it may be conforming ("conforming" is a
>> very loose criterion for programs).
>
> I garbled that. My bad. I meant a compiler that only accepts strictly
> conforming programs. Such compilers are not specifically mentioned in
> the standard but can be assumd to exist. Any program that compiles on
> one is, per the standard, portable to any conforming compiler without
> change. I think this is what gcc means by "pedantic".
A conforming compiler is not permitted to reject a program because it's
not strictly conforming.
The definition of a strictly conforming program is (N1570 4p5):
A strictly conforming program shall use only those features
of the language and library specified in this International
Standard. It shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior,
and shall not exceed any minimum implementation limit.
But (N1570 4p3):
A program that is correct in all other aspects, operating on
correct data, containing unspecified behavior shall be a correct
program and act in accordance with 5.1.2.3.
For example:
#include <stdio.h>
int main(void) {
printf("sizeof (int) = %zu\n", sizeof (int));
}
This program is not strictly conforming (since its behavior is
implementation-defined), but it's a "correct program" as specified in
4p3.
gcc's "-pedantic" option merely causes it to (attempt to) be a
conforming compiler for whatever standard you specify.
--
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-03 08:54 -0700 |
| Message-ID | <39cf9193-5d10-4db9-b766-9452d7c1b0bf@googlegroups.com> |
| In reply to | #64629 |
On Thursday, July 2, 2015 at 4:42:28 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Wednesday, July 1, 2015 at 11:08:11 AM UTC-7, Keith Thompson wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> >> > I gather that error correcting would be possible in a conforming
> >> > compiler. It is strictly compiling where that is not possible.
> >>
> >> I don't know what you mean by "strictly compiling". There is
> >> a concept of "strictly conforming", but it applies to programs,
> >> not to compilers. A compiler (more precisely an implementation)
> >> is either conforming or not. A program using an extension is not
> >> strictly conforming, but it may be conforming ("conforming" is a
> >> very loose criterion for programs).
> >
> > I garbled that. My bad. I meant a compiler that only accepts strictly
> > conforming programs. Such compilers are not specifically mentioned in
> > the standard but can be assumd to exist. Any program that compiles on
> > one is, per the standard, portable to any conforming compiler without
> > change. I think this is what gcc means by "pedantic".
>
> A conforming compiler is not permitted to reject a program because it's
> not strictly conforming.
>
> The definition of a strictly conforming program is (N1570 4p5):
>
> A strictly conforming program shall use only those features
> of the language and library specified in this International
> Standard. It shall not produce output dependent on any
> unspecified, undefined, or implementation-defined behavior,
> and shall not exceed any minimum implementation limit.
>
> But (N1570 4p3):
>
> A program that is correct in all other aspects, operating on
> correct data, containing unspecified behavior shall be a correct
> program and act in accordance with 5.1.2.3.
Once again this paragraph is not in the C90 standard (so far as I
can tell). I don't think the C90 standard has a concept of "correct
program".
I hadn't noticed this before. Appendix G.1 of the C90 standard lists
22 unspecified features. Appendix J.1 of N1570 has many more. One item
is "floating type representation". Doesn't that mean that a strictly
conforming program cannot use floating types?
If so the floating types are essentially excluded from strict
conformity. I haven't thought this through - what exactly does
"not produce output dependent on any unspecified ... behavior"
mean?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-03 10:05 -0700 |
| Message-ID | <ln4mll18ak.fsf@kst-u.example.com> |
| In reply to | #64633 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Thursday, July 2, 2015 at 4:42:28 PM UTC-7, Keith Thompson wrote:
[...]
>> A conforming compiler is not permitted to reject a program because it's
>> not strictly conforming.
>>
>> The definition of a strictly conforming program is (N1570 4p5):
>>
>> A strictly conforming program shall use only those features
>> of the language and library specified in this International
>> Standard. It shall not produce output dependent on any
>> unspecified, undefined, or implementation-defined behavior,
>> and shall not exceed any minimum implementation limit.
>>
>> But (N1570 4p3):
>>
>> A program that is correct in all other aspects, operating on
>> correct data, containing unspecified behavior shall be a correct
>> program and act in accordance with 5.1.2.3.
>
> Once again this paragraph is not in the C90 standard (so far as I
> can tell). I don't think the C90 standard has a concept of "correct
> program".
That paragraph was added in C99.
The C90 standard is obsolete, superseded by C99 and later by C11.
I don't believe it was ever the intent that a C compiler could
reject a program because it's not strictly conforming. That intent
was made explicit in the C99 standard.
> I hadn't noticed this before. Appendix G.1 of the C90 standard lists
> 22 unspecified features. Appendix J.1 of N1570 has many more. One item
> is "floating type representation". Doesn't that mean that a strictly
> conforming program cannot use floating types?
>
> If so the floating types are essentially excluded from strict
> conformity. I haven't thought this through - what exactly does
> "not produce output dependent on any unspecified ... behavior"
> mean?
The representation of floating-point objects is a separate issue from
the behavior of floating-point operations.
A program that outputs the raw representation of a floating-point object
cannot be strictly conforming. A program that uses floating-point can
be strictly conforming, as long as its output doesn't depend on any
unspecified behavior.
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-03 21:57 +0000 |
| Message-ID | <mn70fo$5rq$1@speranza.aioe.org> |
| In reply to | #64636 |
Keith Thompson <kst-u@mib.org> wrote: (snip, someone wrote) >> If so the floating types are essentially excluded from strict >> conformity. I haven't thought this through - what exactly does >> "not produce output dependent on any unspecified ... behavior" >> mean? > The representation of floating-point objects is a separate issue from > the behavior of floating-point operations. > A program that outputs the raw representation of a floating-point object > cannot be strictly conforming. A program that uses floating-point can > be strictly conforming, as long as its output doesn't depend on any > unspecified behavior. Even without looking at the raw bits, floating point results can easily be dependent on the internal representation. -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-04 00:30 -0400 |
| Message-ID | <mn7neu$tvj$1@dont-email.me> |
| In reply to | #64636 |
On 07/03/2015 01:05 PM, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
...
>> I hadn't noticed this before. Appendix G.1 of the C90 standard lists
>> 22 unspecified features. Appendix J.1 of N1570 has many more. One item
>> is "floating type representation". Doesn't that mean that a strictly
>> conforming program cannot use floating types?
>>
>> If so the floating types are essentially excluded from strict
>> conformity. I haven't thought this through - what exactly does
>> "not produce output dependent on any unspecified ... behavior"
>> mean?
When the C standard leaves something merely unspecified (and not, for
example, undefined), there's a range of choices available to the
implementation (in many cases that range is infinitely large). For
example, the number of bytes required to store a 'short int' is
unspecified. It can be as small as 1 (if CHAR_BIT >= 16), and there's no
upper limit on the size.
If the output of your program depends upon which of those choices an
implementation makes, then the program is not strictly conforming. For
example, the following program
#include <stdlib.h>
int main(void)
{
return sizeof(short) == 2 ? EXIT_SUCCESS : EXIT_FAILURE;
}
is not strictly conforming, because sizeof(short) might be 2, or it
might not be 2. I consider the exit status of a program to be part of
it's "output" - other people disagree. If you are one of those people,
use a printf() call instead.
Are you still of the opinion that compilers that accept only strictly
conforming programs are likely to exist, and a good idea?
> The representation of floating-point objects is a separate issue from
> the behavior of floating-point operations.
>
> A program that outputs the raw representation of a floating-point object
> cannot be strictly conforming. A program that uses floating-point can
> be strictly conforming, as long as its output doesn't depend on any
> unspecified behavior.
However, given how little the standard specifies about floating point
behavior, it requires considerable thought to write a
strictly-conforming program that meaningfully makes use of floating
point. I'm sure you know what I'm referring to, but I'm going to explain
the details for David's benefit.
The key issue is 5.2.4.2.2p6: "The accuracy of the floating-point
operations (+, -, *, /) and of the library functions in <math.h> and
<complex.h> that return floating-point results is implementation
defined, as is the accuracy of the conversion between floating-point
internal representations and string representations performed by the
library functions in <stdio.h>, <stdlib.h>, and <wchar.h>. The
implementation may state that the accuracy is unknown."
Thus, a fully conforming implementation of C could implement floating
point subtractions with such poor accuracy that DBL_MAX - DBL_MIN <
DBL_MIN - DBL_MAX, so long as the fact that the accuracy was that bad
was mentioned in the implementation's documentation (that's the
implication of "implementation-defined").
That might seem to render floating point almost completely useless, at
least as far as portable code is concerned. However, there's a few
aspects that are constrained tightly enough to be useful. First of all,
it's only the floating point arithmetic operators (*, -, *, /) and the
other operators whose behavior is defined in terms of those operators
(+=, -=, *=, /=, ++, --) that are covered by 5.2.4.2.2p6; an
implementation has no such freedom with respect to any of the other
operators that can be applied to floating point values, and theres' a
fair number of them (_Generic, !, sizeof, _Alignof, casts, <, >, <=, >=,
==, !=, =, ?:, comma operator).
Secondly, "For decimal floating constants, and also for hexadecimal
floating constants when FLT_RADIX is not a power of 2, the result is
either the nearest representable value, or the larger or smaller
representable value immediately adjacent to the nearest representable
value, chosen in an implementation-defined manner. For hexadecimal
floating constants when FLT_RADIX is a power of 2, the result is
correctly rounded." (6.4.4.2p3). That's a pretty tight constraint. Note:
hexadecimal constants, and the corresponding requirement that they be
correctly rounded when FLT_RADIX is a power of 2, are both new in C99.
C90 had, I believe, only the weaker requirement.
The C standard does define a model floating point representation in
5.2.4.2.2p1-2, but only for the purpose of clearly specifying the
meaning of various constants describing floating point types that are
#defined in <float.h>. An implementation doesn't have to use that model
representation, but does have to provide those constants, and given them
values that reasonably represent the characteristics of the actual
representation used. In particular, it requires that FLT_EPSILON,
DBL_EPSILON, and LDBL_EPSILON be #defined with values no larger than
1e-5, 1E-9 and 1E-9, respectively.
Given those limits, it becomes possible to determine that for a given
pair of floating point constants A and B, that all three of the possible
floating point representations for A must be smaller an any of the three
possible floating point representations of B. If that is the case, then
A < B is guaranteed to be true for all implementations, regardless of
how they implement floating point operations. That's pretty much the
upper limit on how much the behavior of a strictly conforming program
can rely upon the value of a floating point expression.
Note, in particular, that a strictly conforming program can't print out
a floating point value: the conversion between a floating point
representation and a decimal string performed by printf() is one of the
things covered by 5.2.4.2.2p6.
C99 added many floating point features that improve C's floating point
support. However, all of the essential features are optional, so it
doesn't help as far as strictly conforming code is concerned
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-04 08:08 -0700 |
| Message-ID | <71c62ee8-0007-446b-9004-c6def341205a@googlegroups.com> |
| In reply to | #64636 |
On Friday, July 3, 2015 at 10:05:21 AM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > > I hadn't noticed this before. Appendix G.1 of the C90 standard lists > > 22 unspecified features. Appendix J.1 of N1570 has many more. One item > > is "floating type representation". Doesn't that mean that a strictly > > conforming program cannot use floating types? > > > > If so the floating types are essentially excluded from strict > > conformity. I haven't thought this through - what exactly does > > "not produce output dependent on any unspecified ... behavior" > > mean? > > The representation of floating-point objects is a separate issue from > the behavior of floating-point operations. > > A program that outputs the raw representation of a floating-point object > cannot be strictly conforming. A program that uses floating-point can > be strictly conforming, as long as its output doesn't depend on any > unspecified behavior. If the representation of floating point is unspecified how can the size be known? It is easy to write code to give different answers for different values of sizeof (float). Am I, perhaps confusing "implementatio-defined" with "unspecified"? What exactly is the difference.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-07-04 12:21 -0400 |
| Message-ID | <EKTlx.35368$ax2.14572@fx07.iad> |
| In reply to | #64662 |
On 7/4/15 11:08 AM, David Kleinecke wrote: > On Friday, July 3, 2015 at 10:05:21 AM UTC-7, Keith Thompson wrote: > Am I, perhaps confusing "implementatio-defined" with "unspecified"? > What exactly is the difference. > Implementation-defined means that the implementation MUST document the choice in its conformance document. Unspecified means it doesn't have to. Because the implementation must document the behavior, a (non-strictly) conforming program can have known behavior. With unspecified behavior, it could be quite possible for the implementation to choice different options under different (perhaps even subtly) conditions.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-05 09:22 -0700 |
| Message-ID | <89818ea5-b4df-4519-9383-3a704e3670e5@googlegroups.com> |
| In reply to | #64664 |
On Saturday, July 4, 2015 at 9:22:08 AM UTC-7, Richard Damon wrote: > On 7/4/15 11:08 AM, David Kleinecke wrote: > > On Friday, July 3, 2015 at 10:05:21 AM UTC-7, Keith Thompson wrote: > > > Am I, perhaps confusing "implementatio-defined" with "unspecified"? > > What exactly is the difference. > > > > Implementation-defined means that the implementation MUST document the > choice in its conformance document. Unspecified means it doesn't have to. > > Because the implementation must document the behavior, a (non-strictly) > conforming program can have known behavior. With unspecified behavior, > it could be quite possible for the implementation to choice different > options under different (perhaps even subtly) conditions. I didn't know that. I assumed the implementation would document its specifications. Now the question becomes why are some features left optionally undocuemnted?
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-05 09:49 -0700 |
| Message-ID | <5bbf7a34-8d8f-4a2b-bf48-fe174341ff2d@googlegroups.com> |
| In reply to | #64697 |
On Sunday, July 5, 2015 at 9:23:03 AM UTC-7, David Kleinecke wrote: > On Saturday, July 4, 2015 at 9:22:08 AM UTC-7, Richard Damon wrote: > > On 7/4/15 11:08 AM, David Kleinecke wrote: > > > On Friday, July 3, 2015 at 10:05:21 AM UTC-7, Keith Thompson wrote: > > > > > Am I, perhaps confusing "implementatio-defined" with "unspecified"? > > > What exactly is the difference. > > > > > > > Implementation-defined means that the implementation MUST document the > > choice in its conformance document. Unspecified means it doesn't have to. > > > > Because the implementation must document the behavior, a (non-strictly) > > conforming program can have known behavior. With unspecified behavior, > > it could be quite possible for the implementation to choice different > > options under different (perhaps even subtly) conditions. > > I didn't know that. I assumed the implementation would document its > specifications. Now the question becomes why are some features left > optionally undocuemnted? This has been very educational for me. My attitude towards the standards has changed. I think I have considerably less respect for them now. And I am sure I want to reject all the standards after C90. I would call what I want "Core C" except for ... Unfortunately K&R 1978 is not thorough enough to use as a standard (and it omits things). I want a lightweight version of C90. This is IMO what most C programmers code to (except maybe for // comments and statement- declaration mixing. Actually my interest lies not in producing code but in documenting it. If I must assume a reader must know eveything in an unreadable 683 page document I am defeted before I start.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-05 18:16 -0700 |
| Message-ID | <lnd206w0fc.fsf@kst-u.example.com> |
| In reply to | #64699 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Sunday, July 5, 2015 at 9:23:03 AM UTC-7, David Kleinecke wrote:
>> On Saturday, July 4, 2015 at 9:22:08 AM UTC-7, Richard Damon wrote:
>> > On 7/4/15 11:08 AM, David Kleinecke wrote:
>> > > On Friday, July 3, 2015 at 10:05:21 AM UTC-7, Keith Thompson wrote:
>> >
>> > > Am I, perhaps confusing "implementatio-defined" with "unspecified"?
>> > > What exactly is the difference.
>> > >
>> >
>> > Implementation-defined means that the implementation MUST document the
>> > choice in its conformance document. Unspecified means it doesn't have to.
>> >
>> > Because the implementation must document the behavior, a (non-strictly)
>> > conforming program can have known behavior. With unspecified behavior,
>> > it could be quite possible for the implementation to choice different
>> > options under different (perhaps even subtly) conditions.
>>
>> I didn't know that. I assumed the implementation would document its
>> specifications. Now the question becomes why are some features left
>> optionally undocuemnted?
>
> This has been very educational for me. My attitude towards the standards
> has changed. I think I have considerably less respect for them now. And I
> am sure I want to reject all the standards after C90.
Why? The definitions of unspecified, undefined, and
implementation-defined behavior have not changed between C90 and C99,
or between C99 and C11, and the kinds of things in those categories
have not changed substantially.
In most cases, undefined behavior is something that's logically
an error, but where it would be impractical to require all
implementations to detect it in all cases. An example is
signed integer overflow; detecting it in all cases would impose
substantial overhead on all signed integer arithmetic (except
where the compiler can prove that an operation cannot overflow).
(Of course an implementation is free to insert code to check
for overflow; that's one of the infinitely many things that an
implementation can do for undefined behavior.)
Unspecified (but not implementation-defined) behavior is similar:
the authors of the standard did not feel it was worthwhile to
require each implementation to document the behavior. An example
is the order of evaluation of arguments in a function call. In my
opinion, neither specifying the order of evaluation of arguments, nor
requiring each implementation to document how the order of evaluation
is determined, would be worthwhile. Of course an implementation
is free to document the order anyway; I know of none that do so.
> I would call what I want "Core C" except for ...
>
> Unfortunately K&R 1978 is not thorough enough to use as a standard (and
> it omits things). I want a lightweight version of C90. This is IMO what
> most C programmers code to (except maybe for // comments and statement-
> declaration mixing.
>
> Actually my interest lies not in producing code but in documenting it.
> If I must assume a reader must know eveything in an unreadable 683
> page document I am defeted before I start.
If you want to define a modified version of C, I think you need to
understand C as it's currently defined. Likewise if you want to
criticize it. (I don't find the standard unreadable.)
--
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-06 08:37 -0700 |
| Message-ID | <b5a6aef3-e9f0-4a50-9e65-8912d62f8361@googlegroups.com> |
| In reply to | #64730 |
On Sunday, July 5, 2015 at 6:16:17 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Sunday, July 5, 2015 at 9:23:03 AM UTC-7, David Kleinecke wrote: > >> On Saturday, July 4, 2015 at 9:22:08 AM UTC-7, Richard Damon wrote: > >> > On 7/4/15 11:08 AM, David Kleinecke wrote: > >> > > On Friday, July 3, 2015 at 10:05:21 AM UTC-7, Keith Thompson wrote: > >> > > >> > > Am I, perhaps confusing "implementatio-defined" with "unspecified"? > >> > > What exactly is the difference. > >> > > > >> > > >> > Implementation-defined means that the implementation MUST document the > >> > choice in its conformance document. Unspecified means it doesn't have to. > >> > > >> > Because the implementation must document the behavior, a (non-strictly) > >> > conforming program can have known behavior. With unspecified behavior, > >> > it could be quite possible for the implementation to choice different > >> > options under different (perhaps even subtly) conditions. > >> > >> I didn't know that. I assumed the implementation would document its > >> specifications. Now the question becomes why are some features left > >> optionally undocuemnted? > > > > This has been very educational for me. My attitude towards the standards > > has changed. I think I have considerably less respect for them now. And I > > am sure I want to reject all the standards after C90. > > Why? The definitions of unspecified, undefined, and > implementation-defined behavior have not changed between C90 and C99, > or between C99 and C11, and the kinds of things in those categories > have not changed substantially. > > In most cases, undefined behavior is something that's logically > an error, but where it would be impractical to require all > implementations to detect it in all cases. An example is > signed integer overflow; detecting it in all cases would impose > substantial overhead on all signed integer arithmetic (except > where the compiler can prove that an operation cannot overflow). > (Of course an implementation is free to insert code to check > for overflow; that's one of the infinitely many things that an > implementation can do for undefined behavior.) > > Unspecified (but not implementation-defined) behavior is similar: > the authors of the standard did not feel it was worthwhile to > require each implementation to document the behavior. An example > is the order of evaluation of arguments in a function call. In my > opinion, neither specifying the order of evaluation of arguments, nor > requiring each implementation to document how the order of evaluation > is determined, would be worthwhile. Of course an implementation > is free to document the order anyway; I know of none that do so. > > > I would call what I want "Core C" except for ... > > > > Unfortunately K&R 1978 is not thorough enough to use as a standard (and > > it omits things). I want a lightweight version of C90. This is IMO what > > most C programmers code to (except maybe for // comments and statement- > > declaration mixing. > > > > Actually my interest lies not in producing code but in documenting it. > > If I must assume a reader must know eveything in an unreadable 683 > > page document I am defeted before I start. > > If you want to define a modified version of C, I think you need to > understand C as it's currently defined. Likewise if you want to > criticize it. (I don't find the standard unreadable.) I disagree. To my mind C11 is a modified version of C90 with a bad case of creeping featuritis. I have no intention of crticizing C11 or even commenting on it (except perhaps about threads). And I have no intention of changing C. I just want to make C (meaning freestanding C90) easier to read and understand.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-06 12:56 -0400 |
| Message-ID | <559AB33F.8010501@verizon.net> |
| In reply to | #64764 |
On 07/06/2015 11:37 AM, David Kleinecke wrote: > On Sunday, July 5, 2015 at 6:16:17 PM UTC-7, Keith Thompson wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: ... >>> Actually my interest lies not in producing code but in documenting it. >>> If I must assume a reader must know eveything in an unreadable 683 >>> page document I am defeted before I start. I've never seen a copy of C90 - when I needed it, it was too expensive; by the time it was available at a reasonable cost, I had already moved on to C99. I think you've said you have a copy of it? If so, how long was it? >> If you want to define a modified version of C, I think you need to >> understand C as it's currently defined. Likewise if you want to >> criticize it. (I don't find the standard unreadable.) > > I disagree. To my mind C11 is a modified version of C90 with a bad > case of creeping featuritis. I have no intention of crticizing C11 or > even commenting on it (except perhaps about threads). And I have no > intention of changing C. I just want to make C (meaning freestanding > C90) easier to read and understand. Even if all you want to modify is C90, then his comment still stands - with respect to C90. You need to fully understand it before you can reasonably modify or criticize it (unreasonable modifications and criticism require far less understanding, of course). From what I've seen, you've got a long way to go. You're still learning basic concepts like what "unspecified behavior", "implementation-defined behavior" and "undefined behavior" mean. While you've mainly criticized later versions of C, many of your criticisms have been equally applicable to C90 - and those criticisms don't seem to be based in a solid understanding of the purpose of the things you're criticizing.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-06 11:59 -0700 |
| Message-ID | <lnio9xun6g.fsf@kst-u.example.com> |
| In reply to | #64779 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 07/06/2015 11:37 AM, David Kleinecke wrote:
>> On Sunday, July 5, 2015 at 6:16:17 PM UTC-7, Keith Thompson wrote:
>>> David Kleinecke <dkleinecke@gmail.com> writes:
> ...
>>>> Actually my interest lies not in producing code but in documenting it.
>>>> If I must assume a reader must know eveything in an unreadable 683
>>>> page document I am defeted before I start.
>
> I've never seen a copy of C90 - when I needed it, it was too expensive;
> by the time it was available at a reasonable cost, I had already moved
> on to C99. I think you've said you have a copy of it? If so, how long
> was it?
The C90 standard is 230 pages, C99 is 554 pages, and C11 is 702 pages
(those are the full sizes of the PDF documents, including indices and
blank pages).
A note at the bottom of the last page of the C99 PDF says "Price based
on 537 pages"; a similar note at the end of the C11 PDF says "Price
based on 457 pages". I don't know what that's about.
>>> If you want to define a modified version of C, I think you need to
>>> understand C as it's currently defined. Likewise if you want to
>>> criticize it. (I don't find the standard unreadable.)
>>
>> I disagree. To my mind C11 is a modified version of C90 with a bad
>> case of creeping featuritis. I have no intention of crticizing C11 or
>> even commenting on it (except perhaps about threads). And I have no
>> intention of changing C. I just want to make C (meaning freestanding
>> C90) easier to read and understand.
>
> Even if all you want to modify is C90, then his comment still stands -
> with respect to C90. You need to fully understand it before you can
> reasonably modify or criticize it (unreasonable modifications and
> criticism require far less understanding, of course). From what I've
> seen, you've got a long way to go. You're still learning basic concepts
> like what "unspecified behavior", "implementation-defined behavior" and
> "undefined behavior" mean. While you've mainly criticized later versions
> of C, many of your criticisms have been equally applicable to C90 - and
> those criticisms don't seem to be based in a solid understanding of the
> purpose of the things you're criticizing.
David, James wrote pretty much what I was going to. You've said, if I
understand you correctly, that you dislike the idea of "unspecified
behavior" where the implementation is not required to document its
choices. But you've declined to cite any specific example of behavior
that the standard says is unspecified but you think it shouldn't be.
--
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-06 15:45 -0400 |
| Message-ID | <559ADAC7.1000409@verizon.net> |
| In reply to | #64789 |
On 07/06/2015 02:59 PM, Keith Thompson wrote: ... > A note at the bottom of the last page of the C99 PDF says "Price based > on 537 pages"; a similar note at the end of the C11 PDF says "Price > based on 457 pages". I don't know what that's about. Part of that seems very clear to me, part of it is not. I'm not sure whether your "I don't know" is about both parts, or just the latter. The implication of those words is that they have an algorithm for determining the price that depends upon the number of pages, and that the number of pages used for the purposes of that algorithm is smaller for some reason, than the actual number of pages. The unclear part is the nature of the algorithm, and the reason why certain pages don't count.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-06 13:14 -0700 |
| Message-ID | <lny4itavsk.fsf@kst-u.example.com> |
| In reply to | #64792 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 07/06/2015 02:59 PM, Keith Thompson wrote:
> ...
>> A note at the bottom of the last page of the C99 PDF says "Price based
>> on 537 pages"; a similar note at the end of the C11 PDF says "Price
>> based on 457 pages". I don't know what that's about.
>
> Part of that seems very clear to me, part of it is not. I'm not sure
> whether your "I don't know" is about both parts, or just the latter.
>
> The implication of those words is that they have an algorithm for
> determining the price that depends upon the number of pages, and that
> the number of pages used for the purposes of that algorithm is smaller
> for some reason, than the actual number of pages. The unclear part is
> the nature of the algorithm, and the reason why certain pages don't count.
I was mostly bewildered by the fact that C11 is much longer than C99,
but the "price based on" count for C11 is *smaller* than for C99.
--
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 | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-07-07 01:10 -0700 |
| Message-ID | <MPG.30052953cbca5ff24b@news.eternal-september.org> |
| In reply to | #64792 |
James Kuyper wrote: > Keith Thompson wrote: > ... > > A note at the bottom of the last page of the C99 PDF says "Price based > > on 537 pages"; a similar note at the end of the C11 PDF says "Price > > based on 457 pages". I don't know what that's about. > > Part of that seems very clear to me, part of it is not. I'm not sure > whether your "I don't know" is about both parts, or just the latter. > > The implication of those words is that they have an algorithm for > determining the price that depends upon the number of pages, and that > the number of pages used for the purposes of that algorithm is smaller > for some reason, than the actual number of pages. The unclear part is > the nature of the algorithm, and the reason why certain pages don't count. I suspect (with no basis) that it's based on the number of normative pages.
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web