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

Groups > comp.lang.c > #64310 > unrolled thread

More physical source files

Back to article view | Back to comp.lang.c

Contents

  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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#64858

On Monday, July 6, 2015 at 12:00:01 PM UTC-7, Keith Thompson wrote:
> 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.
 
I do dislike the idea of undocumented behavior and I intend to examine
the unspecified material to see why it might to allowed to be 
undocumented. Give me some time please - I hadn't put two and two
together and didn't realize there was anything you could leave
undocumented.

[toc] | [prev] | [next] | [standalone]

#64857

On Monday, July 6, 2015 at 9:56:41 AM UTC-7, James Kuyper wrote:
> 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.

The C90 standard is 219 pages long (through the end of the index). So
far as I can tell the draft called C89 is identical and would serve as
C90. Like everyone else who was writing C code before 1990 my initial
reaction was - how well does this draft conform to what I know as C? 
Not the other way around. 

I had written a couple of C compilers on the basis of what I would
call common knowledge and K&R78. The C90 standard proved to be quite 
handy and quite close to what I would have expected. But I didn't 
spend much time on the fussy little details. 

Recently I have become interested in documenting computer programs 
C seemed like the obvious place to start. But I felt that I needed to
get a better grip on exactly what C meant. One immediate discovery
was that to many people (this group, for example) C meant the hosted
version - the standard library was part of C - and I had been thinking
in terms of free-standing C.  

I have been prodding the standard to understand its standardness - the
C part I'm ok with. The standardness seems very strange to me but I am
beginning to accommodate. 

[toc] | [prev] | [next] | [standalone]

#64867

On 07/07/2015 10:55 AM, David Kleinecke wrote:
...
> The C90 standard is 219 pages long (through the end of the index). So
> far as I can tell the draft called C89 is identical and would serve as
> C90. Like everyone else who was writing C code before 1990 my initial
> reaction was - how well does this draft conform to what I know as C? 
> Not the other way around. 

The final draft was not "called C89". C89 was the official standard, and
I believe that it had a number of minor differences from the final draft.
C89 differs from C90 in only one significant way: C89 is the original
ANSI standard, while C90 is the corresponding ISO standard. All later
versions of the standard have been ISO standards first, and later
approved as ANSI standards without an change in wording.
C90's adoption as an ISO standard imposed additional requirements on the
format. Those requirements were met by adding three sections to the
start of the document. As a result, every clause in C89 has a section
number that is 3 smaller than the corresponding section number in C90
(and all later versions of the standard). I believe that there is
otherwise no significant difference between C89 and C90.

> I had written a couple of C compilers on the basis of what I would
> call common knowledge and K&R78. The C90 standard proved to be quite 
> handy and quite close to what I would have expected. But I didn't 
> spend much time on the fussy little details. 
> 
> Recently I have become interested in documenting computer programs 
> C seemed like the obvious place to start. But I felt that I needed to
> get a better grip on exactly what C meant. One immediate discovery
> was that to many people (this group, for example) C meant the hosted
> version - the standard library was part of C - and I had been thinking
> in terms of free-standing C.

To me, it means both, but I've never used free-standing C, and I've
never written a program that could have usefully performed it's intended
purpose if built within the restrictions of a hosted version of C.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#64912

On Tuesday, July 7, 2015 at 10:13:34 AM UTC-7, James Kuyper wrote:
> On 07/07/2015 10:55 AM, David Kleinecke wrote:
> ...
> > The C90 standard is 219 pages long (through the end of the index). So
> > far as I can tell the draft called C89 is identical and would serve as
> > C90. Like everyone else who was writing C code before 1990 my initial
> > reaction was - how well does this draft conform to what I know as C? 
> > Not the other way around. 
> 
> The final draft was not "called C89". C89 was the official standard, and
> I believe that it had a number of minor differences from the final draft.
> C89 differs from C90 in only one significant way: C89 is the original
> ANSI standard, while C90 is the corresponding ISO standard. All later
> versions of the standard have been ISO standards first, and later
> approved as ANSI standards without an change in wording.
> C90's adoption as an ISO standard imposed additional requirements on the
> format. Those requirements were met by adding three sections to the
> start of the document. As a result, every clause in C89 has a section
> number that is 3 smaller than the corresponding section number in C90
> (and all later versions of the standard). I believe that there is
> otherwise no significant difference between C89 and C90.
 
Thanks for making things explicit. My copy of C90 describes itself as
ANSI/ISO 9899-1990. 

> > I had written a couple of C compilers on the basis of what I would
> > call common knowledge and K&R78. The C90 standard proved to be quite 
> > handy and quite close to what I would have expected. But I didn't 
> > spend much time on the fussy little details. 
> > 
> > Recently I have become interested in documenting computer programs 
> > C seemed like the obvious place to start. But I felt that I needed to
> > get a better grip on exactly what C meant. One immediate discovery
> > was that to many people (this group, for example) C meant the hosted
> > version - the standard library was part of C - and I had been thinking
> > in terms of free-standing C.
> 
> To me, it means both, but I've never used free-standing C, and I've
> never written a program that could have usefully performed it's intended
> purpose if built within the restrictions of a hosted version of C.

Are you sure you didn't lose a negative in there somewhere? It seems
to mean you have never written a C program.

Anyway I'll read what you wrote as saying all your experience has been
with hosted C.

[toc] | [prev] | [next] | [standalone]

#64923

On 07/08/2015 11:35 AM, David Kleinecke wrote:
> On Tuesday, July 7, 2015 at 10:13:34 AM UTC-7, James Kuyper wrote:
...
>> To me, it means both, but I've never used free-standing C, and I've
>> never written a program that could have usefully performed it's intended
>> purpose if built within the restrictions of a hosted version of C.
> 
> Are you sure you didn't lose a negative in there somewhere? It seems
> to mean you have never written a C program.

No, I wrote "hosted" instead of "free-standing" in the last sentence.
That's not a negation, though a missing negation could have been used to
express the same (incorrect) meaning.

> Anyway I'll read what you wrote as saying all your experience has been
> with hosted C.

It's not just that my experience has been exclusively with hosted C.
That would allow for the possibility that I had, at some time, written a
program that could have been run on a free-standing implementation of C,
but I ran it on a hosted one.
Every program I've ever written has required at least one feature of
hosted C (most frequently, the <stdio.h> part of the C standard library).

[toc] | [prev] | [next] | [standalone]

#65015

On Wednesday, July 8, 2015 at 9:31:41 AM UTC-7, James Kuyper wrote:
> On 07/08/2015 11:35 AM, David Kleinecke wrote:
> > On Tuesday, July 7, 2015 at 10:13:34 AM UTC-7, James Kuyper wrote:
> ...
> >> To me, it means both, but I've never used free-standing C, and I've
> >> never written a program that could have usefully performed it's intended
> >> purpose if built within the restrictions of a hosted version of C.
> > 
> > Are you sure you didn't lose a negative in there somewhere? It seems
> > to mean you have never written a C program.
> 
> No, I wrote "hosted" instead of "free-standing" in the last sentence.
> That's not a negation, though a missing negation could have been used to
> express the same (incorrect) meaning.
> 
> > Anyway I'll read what you wrote as saying all your experience has been
> > with hosted C.
> 
> It's not just that my experience has been exclusively with hosted C.
> That would allow for the possibility that I had, at some time, written a
> program that could have been run on a free-standing implementation of C,
> but I ran it on a hosted one.
> Every program I've ever written has required at least one feature of
> hosted C (most frequently, the <stdio.h> part of the C standard library).

In K&R78 <stdio.h> is the library. 

Freestanding was not a good choice of name. I think "unhosted" would
have been better. 

[toc] | [prev] | [next] | [standalone]

#65016

On 09/07/15 16:50, David Kleinecke wrote:
> On Wednesday, July 8, 2015 at 9:31:41 AM UTC-7, James Kuyper wrote:

<snip>

>> Every program I've ever written has required at least one feature of
>> hosted C (most frequently, the <stdio.h> part of the C standard library).
>
> In K&R78 <stdio.h> is the library.

No, it's a header.

The distinction between headers and libraries is significant, and indeed 
vital to an understanding of their respective purposes.

It is reasonable to say, as James did, that <stdio.h> is part of the C 
standard library (because the sources for that library are very likely 
to include it), but it is not reasonable to say that it /is/ the library.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#65062

On Thursday, July 9, 2015 at 4:56:31 PM UTC+1, Richard Heathfield wrote:
>
> It is reasonable to say, as James did, that <stdio.h> is part of the C 
> standard library (because the sources for that library are very likely 
> to include it), but it is not reasonable to say that it /is/ the library.
> 
The C++ way is now to ship libraries as header files. 

It takes all day to get a compiler to link a library and check that 
it works. That's finally been recognised.

[toc] | [prev] | [next] | [standalone]

#65071

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, July 9, 2015 at 4:56:31 PM UTC+1, Richard Heathfield wrote:
>> It is reasonable to say, as James did, that <stdio.h> is part of the C 
>> standard library (because the sources for that library are very likely 
>> to include it), but it is not reasonable to say that it /is/ the library.
>> 
> The C++ way is now to ship libraries as header files. 

I presume that's because much of the C++ library consists of templates.

The C++ standard library c most of the C standard library.  I
don't think that the implementation of printf, for example, is shipped
as a header file.  Similarly, for C++ I'd expect there to be a layer of
non-template code that also wouldn't be included in headers.

> It takes all day to get a compiler to link a library and check that 
> it works. That's finally been recognised.

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

#65079

Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> On Thursday, July 9, 2015 at 4:56:31 PM UTC+1, Richard Heathfield wrote:
>>> It is reasonable to say, as James did, that <stdio.h> is part of the C
>>> standard library (because the sources for that library are very likely
>>> to include it), but it is not reasonable to say that it /is/ the library.
>>>
>> The C++ way is now to ship libraries as header files.
>
> I presume that's because much of the C++ library consists of templates.
>
> The C++ standard library c most of the C standard library.  I
> don't think that the implementation of printf, for example, is shipped
> as a header file.  Similarly, for C++ I'd expect there to be a layer of
> non-template code that also wouldn't be included in headers.

You would be correct in that assumption.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#65137

On Thursday, July 9, 2015 at 8:56:31 AM UTC-7, Richard Heathfield wrote:
> On 09/07/15 16:50, David Kleinecke wrote:
> > On Wednesday, July 8, 2015 at 9:31:41 AM UTC-7, James Kuyper wrote:
> 
> <snip>
> 
> >> Every program I've ever written has required at least one feature of
> >> hosted C (most frequently, the <stdio.h> part of the C standard library).
> >
> > In K&R78 <stdio.h> is the library.
> 
> No, it's a header.
 
I knew that. I was just echoing the usage of the previous sentence.

> The distinction between headers and libraries is significant, and indeed 
> vital to an understanding of their respective purposes.
> 
> It is reasonable to say, as James did, that <stdio.h> is part of the C 
> standard library (because the sources for that library are very likely 
> to include it), but it is not reasonable to say that it /is/ the library.
 
Fidddle-dee-dee. De minimus. In K&R78 the only library header is 
<stdio.h>. 
> Richard Heathfield
> Email: rjh at cpax dot org dot uk
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#65050

On 07/09/2015 11:50 AM, David Kleinecke wrote:
> On Wednesday, July 8, 2015 at 9:31:41 AM UTC-7, James Kuyper wrote:
...
>> Every program I've ever written has required at least one feature of
>> hosted C (most frequently, the <stdio.h> part of the C standard library).
> 
> In K&R78 <stdio.h> is the library.

stdio.h is a header; it describes part of the C standard library. In K&R
C, it described the entirety of the library. However, stdio.h isn't the
library itself.

K&R78 predates, by about a decade, the standard's definitions of
"hosted" and "freestanding" - but what it describes is a better match to
a hosted implementation.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#64702

On 07/05/2015 12:22 PM, David Kleinecke wrote:
> On Saturday, July 4, 2015 at 9:22:08 AM UTC-7, Richard Damon wrote:
...
>> 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? 

The following is not an authoritative statement, but only my best guess
based upon familiarity with the standard.

As a general rule, behavior is implementation-defined if the committee
believed it could be a good idea, for code that didn't need to be
portable, to write code that relies upon the definition provided by the
implementation.

For example: "In a freestanding environment (in which C program
execution may take place without any benefit of an operating system),
the name and type of the function called at program startup are
implementation-defined." (5.1.2.1p1). That function serves the same
purpose in a freestanding environment that main() serves for a hosted
environment. You need to provide a definition of that function, and make
sure it calls the rest of your code, otherwise there's no way to arrange
the rest of your code gets executed. Therefore, it wouldn't be very
useful if the implementation failed to document that name and type.

On the other hand, if something is left only unspecified, and not
implementation-defined, that means that, even for code that doesn't need
to be portable, the committee felt that the best way to deal with the
issue is to write code that does NOT depend upon what choice is made.

For example: "When the processing of the abstract machine is interrupted
by receipt of a signal, the values of objects that are neither lock-free
atomic objects nor of type volatile sig_atomic_t are unspecified, as is
the state of the floating-point environment." (5.1.2.3p5).
Signals interrupt normal execution of a program. If the standard did
mandate documentation of such things, it would effectively be
prohibiting some optimizations, simply because those optimizations would
make it excessively difficult to document what the values would be. This
clause gives a programmer of a signal handler three choices for any
given object: make it a "lock-free atomic" object, make it a "volatile
sig_atomic_t" object, or write your code so it doesn't rely upon the
value of the object at the start of the signal handler. Note that the
first two options have the effect of disabling the same types of
optimizations - but they are disabled only with respect to those
particular objects, not for all objects in general.

Note: I'm not sufficiently familiar with multi-threaded code (support
for multi-threaded programming is new in C2011) to fully appreciate the
implications of making something "lock-free atomic" - but I doubt that
my ignorance is sufficient to render the above comment inaccurate. I
could be wrong about that.

[toc] | [prev] | [next] | [standalone]

#64705

On 7/5/15 12:22 PM, 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?
>

But the standard doesn't require all things to be specified. For 
instance, the size of the various integral types are implementation 
specified, as these are reasonable things to vary from one 
implementation to another (based on machine characteristics for example) 
but a given implementation needs to make a firm decision on what they are.

For other things, like the order of evaluation of parameters to a 
function, giving the implementation the ability to "change its mind" may 
allow for better code. On some machines computing the "more complicated" 
expression first may save time/space (as you don't need to keep the 
other answer around burning up a register). These things are left as 
unspecified. When building the standard, I imagine that they looked at 
the various things that were left unspecified and asked how valuable 
would it be to make the implementation specify this, and be know 
behavior that the programmer writing specifically for this platform, and 
how valuable is it to give the implementation the ability to change this 
from time to time. Many things fall clearly in one camp or the other, 
and I suspect close calls were left unspecified, as the implementation 
always has the option to document it choices in unspecified behavior.

[toc] | [prev] | [next] | [standalone]

#64674

David Kleinecke <dkleinecke@gmail.com> writes:
> 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).

Of course it is.

You can write a program that uses floating-point whose output depends on
unspecified, undefined, or implementation-defined behavior.  Such a
program is not strictly conforming.

You can write a program that uses floating-point whose output *doesn't*
depend on unspecified, undefined, or implementation-defined behavior.
Such a program may be strictly conforming.

> Am I, perhaps confusing "implementatio-defined" with "unspecified"?
> What exactly is the difference. 

The terms are defined in section 3 of the standard.

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

#64675

On Saturday, July 4, 2015 at 8:36:53 PM UTC+1, Keith Thompson wrote:
>
> You can write a program that uses floating-point whose output *doesn't*
> depend on unspecified, undefined, or implementation-defined behavior.
> Such a program may be strictly confoming.
>
A C program can't output reals. It can only output bits, which are
often interpreted as integers or rationals for the user. If you
insist that no integer shall be off by even one place, and you are
face with a perverse implementation designed to break your program,
it becomes difficult to use floating point. Relax the requirements
a bit, and it becomes quite easy.

[toc] | [prev] | [next] | [standalone]

#64676

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, July 4, 2015 at 8:36:53 PM UTC+1, Keith Thompson wrote:
>> You can write a program that uses floating-point whose output *doesn't*
>> depend on unspecified, undefined, or implementation-defined behavior.
>> Such a program may be strictly confoming.
>>
> A C program can't output reals. It can only output bits, which are
> often interpreted as integers or rationals for the user.

Arguable, but I didn't say anything about outputting reals, or even
floating-point values.

>                                                          If you
> insist that no integer shall be off by even one place, and you are
> face with a perverse implementation designed to break your program,
> it becomes difficult to use floating point. Relax the requirements
> a bit, and it becomes quite easy.

Using floating-point in a strictly conforming program is difficult,
given C's lax requirements for floating-point precision.  (On the
other hand, strict conformance is not usually a requirement;
reasonable portability is almost always good enough.)

For example, I believe this program:

    #include <stdio.h>
    int main(void) {
        if (0.0 < 1.0) puts("ok");
        else           puts("OOPS");
    }

is strictly conforming (ignoring the possibility of errors on the puts()
call).  This program:

    #include <stdio.h>
    int main(void) {
        if (1.0 + 1.0 > 1.0) puts("ok");
        else                 puts("OOPS");
    }

is probably not strictly conforming, given that the accuracy of
floating-point "+" is implementation-defined (N1570 5.2.4.2.2p6).
On the other hand, I would argue that if the program prints "OOPS",
then the implementation violates N1570 6.5.6p5:

    The result of the binary + operator is the sum of the operands.

But there's no good way to define how much of an error would render
an implementation non-conforming.

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

#64677

On 07/04/2015 06:42 PM, Keith Thompson wrote:
...
> call).  This program:
> 
>     #include <stdio.h>
>     int main(void) {
>         if (1.0 + 1.0 > 1.0) puts("ok");
>         else                 puts("OOPS");
>     }
> 
> is probably not strictly conforming, given that the accuracy of
> floating-point "+" is implementation-defined (N1570 5.2.4.2.2p6).
> On the other hand, I would argue that if the program prints "OOPS",
> then the implementation violates N1570 6.5.6p5:
> 
>     The result of the binary + operator is the sum of the operands.

5.2.4.2.2p6 prevents 6.5.6p5 from being used to disallow "OOPS". I don't
approve of that fact. I think the standard should have imposed a
reasonable upper limit on the errors. I think the committee avoided
doing so because it would require a lot of complicated wording to
specify the maximum error in a more reasonable fashion. ISO/IEC 60559
contains such wording, and C allows you to check for ISO/IEC 60559
conformance, but I thinks that C itself should have imposed some
requirements of it's own, which need not be as strict at the ISO/IEC
60559 requirements.

[toc] | [prev] | [next] | [standalone]

#64686

On Saturday, July 4, 2015 at 11:42:27 PM UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
>     #include <stdio.h>
>     int main(void) {
>         if (1.0 + 1.0 > 1.0) puts("ok");
>         else                 puts("OOPS");
>     }
> 
> is probably not strictly conforming, given that the accuracy of
> floating-point "+" is implementation-defined (N1570 5.2.4.2.2p6).
> On the other hand, I would argue that if the program prints "OOPS",
> then the implementation violates N1570 6.5.6p5:
> 
>     The result of the binary + operator is the sum of the operands.
> 
> But there's no good way to define how much of an error would render
> an implementation non-conforming.
> 
if(1 + x > 1)

is actually a special case. DBL_EPSILON is the smallest value of x for which 
the expression holds true.

[toc] | [prev] | [next] | [standalone]

#64695

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, July 4, 2015 at 11:42:27 PM UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> 
>>     #include <stdio.h>
>>     int main(void) {
>>         if (1.0 + 1.0 > 1.0) puts("ok");
>>         else                 puts("OOPS");
>>     }
>> 
>> is probably not strictly conforming, given that the accuracy of
>> floating-point "+" is implementation-defined (N1570 5.2.4.2.2p6).
>> On the other hand, I would argue that if the program prints "OOPS",
>> then the implementation violates N1570 6.5.6p5:
>> 
>>     The result of the binary + operator is the sum of the operands.
>> 
>> But there's no good way to define how much of an error would render
>> an implementation non-conforming.
>> 
> if(1 + x > 1)
>
> is actually a special case. DBL_EPSILON is the smallest value of x for which 
> the expression holds true.

How is that relevant?  I was specifically referring to the expression
`1.0 + 1.0 > 1.0`, which is obviously true mathematically, but whose
result is in principle implementation-defined because the precision of
"+" is implementation-defined.  Replacing 1.0 by DBL_EPSILON just
weakens the point.

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web