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

Unspecified behavior in C

Started by	David Kleinecke <dkleinecke@gmail.com>
First post	2015-07-07 14:44 -0700
Last post	2015-07-07 22:30 -0400
Articles	20 on this page of 131 — 17 participants

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

  Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-07 14:44 -0700
    Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-07 15:34 -0700
      Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-08 08:47 -0700
        Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-08 09:11 -0700
          Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-08 10:24 -0700
            Re: Unspecified behavior in C John Bode <jfbode1029@gmail.com> - 2015-07-08 10:46 -0700
            Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-08 13:54 -0400
            Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-08 11:12 -0700
              Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-09 09:15 -0700
                Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 17:33 +0100
                  Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-10 09:24 -0700
                    Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-10 12:54 -0400
                Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-09 10:58 -0700
                  Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-10 09:33 -0700
                    Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-10 12:11 -0700
                      Re: Unspecified behavior in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 21:05 +0000
                        Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-10 17:14 -0700
                          Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-11 09:32 -0700
                            Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-11 12:59 -0400
                            Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-11 17:21 -0700
                      Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-11 09:23 -0700
                        Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-11 13:03 -0400
                        Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-11 17:15 -0700
                          Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-12 09:52 -0700
                            Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-12 14:13 -0400
                              Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-13 09:02 -0700
                                Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-13 13:18 -0400
                                  Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-13 11:09 -0700
                                    Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-13 15:06 -0400
                                      Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 08:14 -0700
                                        Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-14 12:02 -0400
                                Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-13 12:03 -0700
                                  Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 07:54 -0700
                                    Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-14 11:16 -0400
                                    Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-14 16:17 +0100
                                      Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 09:16 -0700
                                        Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-14 12:29 -0400
                                          Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-14 14:57 -0400
                                            Re: Unspecified behavior in C Öö Tiib <ootiib@hot.ee> - 2015-07-14 13:12 -0700
                                              Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-14 16:30 -0400
                                                Re: Unspecified behavior in C Öö Tiib <ootiib@hot.ee> - 2015-07-14 15:54 -0700
                                                  Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-14 21:41 -0500
                                                    Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-14 21:51 -0500
                                                      Re: Unspecified behavior in C Öö Tiib <ootiib@hot.ee> - 2015-07-15 12:42 -0700
                                                        Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-15 16:13 -0500
                                                        Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-16 08:49 -0500
                                                          Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 10:10 -0700
                                                            Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-20 13:24 -0500
                                                              Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 02:56 -0700
                                                                Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-23 11:26 -0500
                                                                  Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-26 11:24 -0700
                                                                Re: Unspecified behavior in C Morris Dovey <mrdovey@iedu.com> - 2015-07-23 19:03 -0500
                                            Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 21:19 -0700
                                              Re: Unspecified behavior in C Martin Shobe <martin.shobe@yahoo.com> - 2015-07-15 23:45 -0500
                                              Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-16 01:37 -0400
                                              Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-16 09:42 +0100
                                                Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:05 -0700
                                                  Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:32 +0100
                                                  Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-16 21:07 -0400
                                                  We're good - don't you worry 'bout a thing, babe (Was: Unspecified behavior in C) gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-17 07:21 +0000
                                                  Re: Unspecified behavior in C raltbos@xs4all.nl (Richard Bos) - 2015-07-19 20:59 +0000
                                                    Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-19 22:02 +0100
                                              Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-16 17:59 -0400
                                              Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-16 23:09 -0400
                                                Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-17 18:48 -0700
                                                  Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-17 23:09 -0400
                                              Re: Unspecified behavior in C raltbos@xs4all.nl (Richard Bos) - 2015-07-19 20:57 +0000
                                                Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-19 17:22 -0400
                                                  Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-19 18:57 -0700
                                                    Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-19 22:16 -0400
                                                      Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-19 19:30 -0700
                                              Re: Unspecified behavior in C John Bode <jfbode1029@gmail.com> - 2015-07-30 14:20 -0700
                                                Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-30 15:30 -0700
                                                  Re: Unspecified behavior in C John Bode <jfbode1029@gmail.com> - 2015-07-30 15:53 -0700
                                                Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-30 16:46 -0700
                                                  Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-31 00:59 -0400
                                                    Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-31 17:15 -0700
                                                      Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-31 18:28 -0700
                                                      Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-31 23:28 -0400
                                                        Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 04:07 -0700
                                                          Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-08-04 18:02 -0700
                                                            Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-04 21:27 -0400
                                                            Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-24 09:33 -0700
                                                              Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-08-24 17:11 -0700
                                                                Re: Unspecified behavior in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 12:44 -0700
                                                      Re: Unspecified behavior in C Ken Brody <kenbrody@spamcop.net> - 2015-08-03 12:09 -0400
                                                        Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-03 13:26 -0400
                                                          Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-08-03 17:53 -0700
                                                            Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-08-03 18:44 -0700
                                                              Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-08-04 17:59 -0700
                                                                Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-08-05 02:23 +0100
                                                                Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-04 21:39 -0400
                                                                Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-08-04 19:27 -0700
                                                            Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-04 00:25 -0400
                                                          Re: Unspecified behavior in C Ken Brody <kenbrody@spamcop.net> - 2015-08-04 11:55 -0400
                                                            Re: Unspecified behavior in C Philip Lantz <prl@canterey.us> - 2015-08-04 10:31 -0700
                                                            Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-04 13:32 -0400
                                                              Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-04 22:46 -0400
                                                            Re: Unspecified behavior in C Ken Brody <kenbrody@spamcop.net> - 2015-08-10 12:16 -0400
                                                              Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-10 13:26 -0400
                                                        Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-08-03 17:46 -0700
                                                          Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-08-05 12:34 -0400
                                        Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-14 17:57 +0100
                                          Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 10:31 -0700
                                            Re: Unspecified behavior in C Richard Heathfield <rjh@cpax.org.uk> - 2015-07-14 18:50 +0100
                                              Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 20:59 -0700
                                        Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-14 11:34 -0700
                                        Re: Unspecified behavior in C raltbos@xs4all.nl (Richard Bos) - 2015-07-19 20:46 +0000
                            Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-12 12:07 -0700
                              Re: Unspecified behavior in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 19:53 +0000
                                Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-12 16:12 -0400
                Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-09 14:20 -0400
                  Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-09 12:18 -0700
                  Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-10 09:47 -0700
                    Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-10 13:36 -0400
                      Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-11 09:19 -0700
                        Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-11 12:56 -0400
                        Re: Unspecified behavior in C gordonb.j19di@burditt.org (Gordon Burditt) - 2015-07-11 20:36 -0500
                          Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-12 10:10 -0700
                Re: Unspecified behavior in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 20:13 +0100
            Re: Unspecified behavior in C raltbos@xs4all.nl (Richard Bos) - 2015-07-09 11:17 +0000
          Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-08 10:37 -0700
            Re: Unspecified behavior in C John Bode <jfbode1029@gmail.com> - 2015-07-08 10:51 -0700
            Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-08 14:14 -0400
            Re: Unspecified behavior in C Keith Thompson <kst-u@mib.org> - 2015-07-08 12:19 -0700
        Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-08 12:14 -0400
          Re: Unspecified behavior in C David Kleinecke <dkleinecke@gmail.com> - 2015-07-08 10:40 -0700
            Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-08 14:29 -0400
              Re: Unspecified behavior in C raltbos@xs4all.nl (Richard Bos) - 2015-07-09 11:20 +0000
        Re: Unspecified behavior in C Robert Wessel <robertwessel2@yahoo.com> - 2015-07-09 02:30 -0500
    Re: Unspecified behavior in C James Kuyper <jameskuyper@verizon.net> - 2015-07-07 22:30 -0400

Page 1 of 7 [1] 2 3 4 5 6 7 Next page →

#64878 — Unspecified behavior in C

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-07-07 14:44 -0700
Subject	Unspecified behavior in C
Message-ID	<353ff1a5-5e38-4791-9e5b-2c3d6589079c@googlegroups.com>

Unspecified Behaviors in C90 - part 1

Appendix G.1 to the 1990 ISO Standard lists 22 unspecified behaviors 
recognized by the standard.  These behaviors are of interest because an implementation of C is not required to document them.

	1. The  manner and timing of static initialization (5.1.2)

5.1.2 says "All objects in static storage shall be initialized (set to 
their initial values) before program startup. The manner and timing of 
such initialization are otherwise unspecified. There are otherwise no 
reserved external identifiers."

"Static" appears to refer to the storage durations of objects (6.1.2.4) 
where two durations are defined - static and automatic. Static duration 
applies to all objects declared outside of functions (and inside if
specifically called static). The program startup is a call to a 
function (main if hosted). It appears that the standard considers this initialization a function (probably automatic) of the loader (if any) 
and therefore not a matter for the program proper. I think the standard 
should make the interface to the loader (if any) explicit.

It appears I favor a standard that reaches all the way back to a
program's form in permanent storage. That opens a can of worms.

[toc] | [next] | [standalone]

#64883

From	Keith Thompson <kst-u@mib.org>
Date	2015-07-07 15:34 -0700
Message-ID	<ln1tgjbnqp.fsf@kst-u.example.com>
In reply to	#64878

David Kleinecke <dkleinecke@gmail.com> writes:
> Unspecified Behaviors in C90 - part 1
>
> Appendix G.1 to the 1990 ISO Standard lists 22 unspecified behaviors
> recognized by the standard.  These behaviors are of interest because
> an implementation of C is not required to document them.
>
> 	1. The  manner and timing of static initialization (5.1.2)
>
> 5.1.2 says "All objects in static storage shall be initialized (set to 
> their initial values) before program startup. The manner and timing of 
> such initialization are otherwise unspecified. There are otherwise no 
> reserved external identifiers."
>
> "Static" appears to refer to the storage durations of objects
> (6.1.2.4) where two durations are defined - static and
> automatic.

C90 neglected to mention "allocated" storage duration, for objects
allocated by malloc() and friends.  C99 added it.  C11 adds thread
storage duration, for objects that exist during the execution of the
thread that created them.

>            Static duration applies to all objects declared outside of
> functions (and inside if specifically called static). The program
> startup is a call to a function (main if hosted). It appears that the
> standard considers this initialization a function (probably automatic)
> of the loader (if any) and therefore not a matter for the program
> proper. I think the standard should make the interface to the loader
> (if any) explicit.

Why?  How would this interface be defined, and how would programmers
benefit from such a definition?

If I write:

    static int x = 10;
    static int y = 20;

the standard says that x and y are initialized to 10 and 20,
respectively, some time before entry to the main function (or, for a
freestanding implementation, to the implementation-defined entry point).
The way in which these initializations happen, and the order in which
they occur, is unspecified.

Initializers for static objects must be constant expressions, so side
effects are not an issue.

It has never occurred to me to care about the order in which these
initializations happen.  They're done before any of my code executes.
Do you really want to require all implementations to document this
irrelevant detail?

> It appears I favor a standard that reaches all the way back to a
> program's form in permanent storage. That opens a can of worms.  

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

#64914

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-07-08 08:47 -0700
Message-ID	<ac8f0089-98d6-466a-afb2-eb5bfc12d88a@googlegroups.com>
In reply to	#64883

On Tuesday, July 7, 2015 at 3:35:04 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > Unspecified Behaviors in C90 - part 1
> >
> > Appendix G.1 to the 1990 ISO Standard lists 22 unspecified behaviors
> > recognized by the standard.  These behaviors are of interest because
> > an implementation of C is not required to document them.
> >
> > 	1. The  manner and timing of static initialization (5.1.2)
> >
> > 5.1.2 says "All objects in static storage shall be initialized (set to 
> > their initial values) before program startup. The manner and timing of 
> > such initialization are otherwise unspecified. There are otherwise no 
> > reserved external identifiers."
> >
> > "Static" appears to refer to the storage durations of objects
> > (6.1.2.4) where two durations are defined - static and
> > automatic.
> 
> C90 neglected to mention "allocated" storage duration, for objects
> allocated by malloc() and friends.  C99 added it.  C11 adds thread
> storage duration, for objects that exist during the execution of the
> thread that created them.
> 
> >            Static duration applies to all objects declared outside of
> > functions (and inside if specifically called static). The program
> > startup is a call to a function (main if hosted). It appears that the
> > standard considers this initialization a function (probably automatic)
> > of the loader (if any) and therefore not a matter for the program
> > proper. I think the standard should make the interface to the loader
> > (if any) explicit.
> 
> Why?  How would this interface be defined, and how would programmers
> benefit from such a definition?
> 
> If I write:
> 
>     static int x = 10;
>     static int y = 20;
> 
> the standard says that x and y are initialized to 10 and 20,
> respectively, some time before entry to the main function (or, for a
> freestanding implementation, to the implementation-defined entry point).
> The way in which these initializations happen, and the order in which
> they occur, is unspecified.
> 
> Initializers for static objects must be constant expressions, so side
> effects are not an issue.
> 
> It has never occurred to me to care about the order in which these
> initializations happen.  They're done before any of my code executes.
> Do you really want to require all implementations to document this
> irrelevant detail?
> 
> > It appears I favor a standard that reaches all the way back to a
> > program's form in permanent storage. That opens a can of worms.  
 
All I'm asking of the standard is that it ask implementators to
document what they are doing. Consider an embedded program that is
hardwired into a device. They should document where the initialized
data is - it might be in the program and accessed there. It might be
in the program and transferred to active memory before startup. I am
no expert on embedded systems. But what it must be should be
documented.

In the same way (see my final paragraph) I think the standard should
require the form of the compiler output and other suchlike matters to
be documented. I don't care how they are done - but they should be
documented.

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

#64918

From	Keith Thompson <kst-u@mib.org>
Date	2015-07-08 09:11 -0700
Message-ID	<lnoajmaatx.fsf@kst-u.example.com>
In reply to	#64914

David Kleinecke <dkleinecke@gmail.com> writes:
> On Tuesday, July 7, 2015 at 3:35:04 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
[...]
>> >            Static duration applies to all objects declared outside of
>> > functions (and inside if specifically called static). The program
>> > startup is a call to a function (main if hosted). It appears that the
>> > standard considers this initialization a function (probably automatic)
>> > of the loader (if any) and therefore not a matter for the program
>> > proper. I think the standard should make the interface to the loader
>> > (if any) explicit.
>> 
>> Why?  How would this interface be defined, and how would programmers
>> benefit from such a definition?
[...]
>> > It appears I favor a standard that reaches all the way back to a
>> > program's form in permanent storage. That opens a can of worms.  
>  
> All I'm asking of the standard is that it ask implementators to
> document what they are doing. Consider an embedded program that is
> hardwired into a device. They should document where the initialized
> data is - it might be in the program and accessed there. It might be
> in the program and transferred to active memory before startup. I am
> no expert on embedded systems. But what it must be should be
> documented.
>
> In the same way (see my final paragraph) I think the standard should
> require the form of the compiler output and other suchlike matters to
> be documented. I don't care how they are done - but they should be
> documented.

You're just repeating your original assertion.  You say, repeatedly,
that the behavior *should* be documented.  You haven't explained
*why* it should be documented, or shown any benefit from such
a requirement.

Any information that's actually relevant to programmers probably
already is documented, whether the standard requires it or not.
If your compiler fails to document something that you actually need
to know, complain to your compiler vendor.

If I define two objects with static storage duration, I do not
know or care in which order they're initialized.  I see no benefit,
and some significant cost, in a requirement to document the order.

Let's take another example.  The order in which arguments in a
function call are evaluated is unspecified.  If I write:

    func(arg1, arg2, arg3);

the three arguments may be evaluated in any of 6 orders.
In practice, that order might depend on the optimization level, or
on the number of registers used in the evaluation of the argument
expressions (the latter can be used to avoid spilling registers to
memory).  It can change from one version of the compiler to another.
The compile-time determination of the evaluation order can be so
complex and arbitrary that the best way to document it would be to
provide the source code of the compiler.

As long as the semantics are implemented correctly, I do not care about
the order in which the arguments are evaluated.

Compiler vendors are already free to document anything they like *if
they choose to*.  Nobody is going to produce documentation for
irrelevant choices because you thinkÿ they "should".

Again, what benefit would such a requirement have?  (If you can answer
that without using the word "should", I'll be impressed.)

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

#64938

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-07-08 10:24 -0700
Message-ID	<97928b10-0689-4a44-b516-56fdadf9e39a@googlegroups.com>
In reply to	#64918

On Wednesday, July 8, 2015 at 9:11:33 AM UTC-7, Keith Thompson wrote:
> 
> If I define two objects with static storage duration, I do not
> know or care in which order they're initialized.  I see no benefit,
> and some significant cost, in a requirement to document the order.
>
> Let's take another example.  The order in which arguments in a
> function call are evaluated is unspecified.  If I write:
> 
>     func(arg1, arg2, arg3);
> 
> the three arguments may be evaluated in any of 6 orders.

Actually this is documented. They may be evaluated in any order.

We are having trouble with the word "unspecified". I suspect that
initially all behavior not specified in the standard was called 
"unspecified" and that "implementation-defined" came later. But
this is a kind of unspecified where a small number of obvious
alternatives might occur depending on essentially uncontrollable 
matters. That is very different than some other kinds of
unspecification.  

Perhaps this should be called "unpredicable".

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

#64944

From	John Bode <jfbode1029@gmail.com>
Date	2015-07-08 10:46 -0700
Message-ID	<8416e8bf-8ffa-48fc-97c2-f832c71d60d6@googlegroups.com>
In reply to	#64938

On Wednesday, July 8, 2015 at 12:25:09 PM UTC-5, David Kleinecke wrote:
> On Wednesday, July 8, 2015 at 9:11:33 AM UTC-7, Keith Thompson wrote:
> > 
> > If I define two objects with static storage duration, I do not
> > know or care in which order they're initialized.  I see no benefit,
> > and some significant cost, in a requirement to document the order.
> >
> > Let's take another example.  The order in which arguments in a
> > function call are evaluated is unspecified.  If I write:
> > 
> >     func(arg1, arg2, arg3);
> > 
> > the three arguments may be evaluated in any of 6 orders.
> 
> Actually this is documented. They may be evaluated in any order.
> 

Documented by the *implementation*?  Are you sure about that?  

> We are having trouble with the word "unspecified". I suspect that
> initially all behavior not specified in the standard was called 
> "unspecified" and that "implementation-defined" came later. 

Let's revisit the definitions:

      3.4.1
    1 implementation-defined behavior
      unspecified behavior where each implementation documents 
      how the choice is made

    2 EXAMPLE An example of implementation-defined behavior is 
      the propagation of the high-order bit when a signed integer 
      is shifted right.
      ...
      3.4.4
    1 unspecified behavior
      use of an unspecified value, or other behavior where this
      International Standard provides two or more possibilities 
      and imposes no further requirements on which is chosen in 
      any instance

    2 EXAMPLE An example of unspecified behavior is the order in 
      which the arguments to a function are evaluated.


> But this is a kind of unspecified where a small number of obvious
> alternatives might occur depending on essentially uncontrollable 
> matters. That is very different than some other kinds of
> unspecification.  
> 
> Perhaps this should be called "unpredicable".

You still haven't explained *why* static initialization order needs to be
documented.  Isn't that determined by the loader, not the compiler?

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

#64947

From	James Kuyper <jameskuyper@verizon.net>
Date	2015-07-08 13:54 -0400
Message-ID	<559D63E6.8060304@verizon.net>
In reply to	#64938

On 07/08/2015 01:24 PM, David Kleinecke wrote:
> On Wednesday, July 8, 2015 at 9:11:33 AM UTC-7, Keith Thompson wrote:
>>
>> If I define two objects with static storage duration, I do not
>> know or care in which order they're initialized.  I see no benefit,
>> and some significant cost, in a requirement to document the order.
>>
>> Let's take another example.  The order in which arguments in a
>> function call are evaluated is unspecified.  If I write:
>>
>>     func(arg1, arg2, arg3);
>>
>> the three arguments may be evaluated in any of 6 orders.
> 
> Actually this is documented. They may be evaluated in any order.

That's what he just said. It "is documented", as you say, by saying that
the "Except as specified later (for the function-call (), &&, ||, ?:,
and comma operators), the order of evaluation of subexpressions and the
order in which side effects take place are both unspecified." (6.5p3) -
which is what he was referring to. The arguments of a function are
sub-expression of the function call expression.

Note, this is the wording in C99. The wording in C2011 has gotten a bit
more complicated, because C2011 allows for multi-threaded code. This has
required the addition of new terminology to be more precise about when
events are (and are not) required to occur in a specific sequence. and
the new version is written using that terminology:

"Except as specified later, side effects and value computations of
subexpressions are unsequenced." (6.5p3).

> We are having trouble with the word "unspecified". I suspect that
> initially all behavior not specified in the standard was called 
> "unspecified" and that "implementation-defined" came later. But
> this is a kind of unspecified where a small number of obvious
> alternatives might occur depending on essentially uncontrollable 
> matters. That is very different than some other kinds of
> unspecification.  
> 
> Perhaps this should be called "unpredicable".

That causes problems with applied to behavior that is (for a given
platform) perfectly predictable - and I can't think of any behavior
labeled by the standard as "unspecified" which is completely incapable
of being predicted on all platforms (though, in many cases, prediction
would be incredibly difficult).

Everything a programmer needs to know about such behavior is conveyed
perfectly by the term "unspecified" - that means that code intended to
be portable must be written to cope in an appropriate fashion with all
of the allowed possibilities. That would still be true if it were
labeled "unpredictable".

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

#64951

From	Keith Thompson <kst-u@mib.org>
Date	2015-07-08 11:12 -0700
Message-ID	<lnh9pea57n.fsf@kst-u.example.com>
In reply to	#64938

David Kleinecke <dkleinecke@gmail.com> writes:
> On Wednesday, July 8, 2015 at 9:11:33 AM UTC-7, Keith Thompson wrote:
>> If I define two objects with static storage duration, I do not
>> know or care in which order they're initialized.  I see no benefit,
>> and some significant cost, in a requirement to document the order.
>>
>> Let's take another example.  The order in which arguments in a
>> function call are evaluated is unspecified.  If I write:
>> 
>>     func(arg1, arg2, arg3);
>> 
>> the three arguments may be evaluated in any of 6 orders.
>
> Actually this is documented. They may be evaluated in any order.

Yes, but the order is unspecified.  We're talking about unspecified
behavior; this is an example of it.

> We are having trouble with the word "unspecified". I suspect that
> initially all behavior not specified in the standard was called 
> "unspecified" and that "implementation-defined" came later. But
> this is a kind of unspecified where a small number of obvious
> alternatives might occur depending on essentially uncontrollable 
> matters. That is very different than some other kinds of
> unspecification.  
>
> Perhaps this should be called "unpredicable".

I think "unspecified" is more accurate.  There is no requirement
for the order to be predictable; it might be perfectly predicatable,
given knowledge of how a particular compiler happens to behave.

I get the general impression that you dislike the idea of unspecified
behavior that is not implementation-defined, and would prefer it, in
some, many, or perhaps all cases, to be implementation-defined behavior
(i.e., implementations should be required to document their choices).
Is that a fair statement?

Does this apply to *everything* that the standard currently says
is unspecified but not implementation-defined?

Personally, I find the standard's choices of which behaviors are
undefined vs. unspecified vs. implementation-defined *mostly*
reasonable.  I think you're advocating additional requirements on
all implementations that have insufficient benefit to justify them.

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

#65021

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-07-09 09:15 -0700
Message-ID	<cb5f75e3-44fb-484d-a017-47e53b339c53@googlegroups.com>
In reply to	#64951

On Wednesday, July 8, 2015 at 11:12:57 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Wednesday, July 8, 2015 at 9:11:33 AM UTC-7, Keith Thompson wrote:
> >> If I define two objects with static storage duration, I do not
> >> know or care in which order they're initialized.  I see no benefit,
> >> and some significant cost, in a requirement to document the order.
> >>
> >> Let's take another example.  The order in which arguments in a
> >> function call are evaluated is unspecified.  If I write:
> >> 
> >>     func(arg1, arg2, arg3);
> >> 
> >> the three arguments may be evaluated in any of 6 orders.
> >
> > Actually this is documented. They may be evaluated in any order.
> 
> Yes, but the order is unspecified.  We're talking about unspecified
> behavior; this is an example of it.
> 
> > We are having trouble with the word "unspecified". I suspect that
> > initially all behavior not specified in the standard was called 
> > "unspecified" and that "implementation-defined" came later. But
> > this is a kind of unspecified where a small number of obvious
> > alternatives might occur depending on essentially uncontrollable 
> > matters. That is very different than some other kinds of
> > unspecification.  
> >
> > Perhaps this should be called "unpredicable".
> 
> I think "unspecified" is more accurate.  There is no requirement
> for the order to be predictable; it might be perfectly predicatable,
> given knowledge of how a particular compiler happens to behave.
> 
> I get the general impression that you dislike the idea of unspecified
> behavior that is not implementation-defined, and would prefer it, in
> some, many, or perhaps all cases, to be implementation-defined behavior
> (i.e., implementations should be required to document their choices).
> Is that a fair statement?
> 
> Does this apply to *everything* that the standard currently says
> is unspecified but not implementation-defined?
> 
> Personally, I find the standard's choices of which behaviors are
> undefined vs. unspecified vs. implementation-defined *mostly*
> reasonable.  I think you're advocating additional requirements on
> all implementations that have insufficient benefit to justify them.
 
You are correct. I want all the "unspecified" behavior documented.

My current hypothesis is that in the earlier drafts of the C90
standard all the behavior now called implementation-defined was 
called "unspecified". That later on the implementation-defined
nomenclature was introduced - but not all instances of
unspecified were updated. There are other signs of haste in the
standard (eg "sizeof" as an operator). 

PS: As I have said elsewhere I object to section 5.2.2 entirely and,
as I will say, I think a matter like whether "errno" is a macro is
already documented because what errno is is stated in the header
<errno.h> which the user can read (in any sane development
environment).

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

#65025

From	Richard Heathfield <rjh@cpax.org.uk>
Date	2015-07-09 17:33 +0100
Message-ID	<mnm7n2$l5k$1@dont-email.me>
In reply to	#65021

On 09/07/15 17:15, David Kleinecke wrote:
> On Wednesday, July 8, 2015 at 11:12:57 AM UTC-7, Keith Thompson wrote:

<snip>

>> Personally, I find the standard's choices of which behaviors are
>> undefined vs. unspecified vs. implementation-defined *mostly*
>> reasonable.  I think you're advocating additional requirements on
>> all implementations that have insufficient benefit to justify them.
>
> You are correct. I want all the "unspecified" behavior documented.

Keith has already pointed out that this documentation game isn't worth 
the implementation's candle. There is no benefit in your proposal that I 
can see. "I want" is sufficient justification for buying a DVD or an 
ornament for the shelf or a space hopper, but it is not sufficient for 
changing an international standard. You need to come up with a why.

> My current hypothesis is that in the earlier drafts of the C90
> standard all the behavior now called implementation-defined was
> called "unspecified". That later on the implementation-defined
> nomenclature was introduced - but not all instances of
> unspecified were updated.

Do you have any evidence in favour of this hypothesis? I have some 
evidence against it. The C90 standard comprised the ANSI C Standard of 
1989 and a few extra sections at the beginning for the sake of meeting 
ISO's documentation standards. So there were no changes between "earlier 
drafts of the C90 standard" that resulted in a shift from unspecified to 
implementation-defined behaviour.

> There are other signs of haste in the
> standard (eg "sizeof" as an operator).

As an operator, sizeof works very well. As a function, it would work 
very badly - it would require properties that no other function has.

> PS: As I have said elsewhere I object to section 5.2.2 entirely and,
> as I will say, I think a matter like whether "errno" is a macro is
> already documented because what errno is is stated in the header
> <errno.h> which the user can read (in any sane development
> environment).

Well, errno is an unusual case. I can only think of two non-conformances 
of Borland's C compiler, and that's one of them - getting a C program to 
work with errno under Borland is not easy (in fact, I never managed it). 
I think errno /is/ poorly specified and poorly designed. But I don't 
think that requiring the implementation to define whether or not it is a 
macro would help.

As for reading headers, one of the most frustrating aspects of gcc is 
that sometimes one /is/ tempted to peek in the headers, and that's when 
it turns out that it's not actually possible to find anything (unless, 
of course, you speak gcc, which I don't).

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

#65132

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-07-10 09:24 -0700
Message-ID	<396cafd2-b61c-4a65-a21e-2b1fa375419d@googlegroups.com>
In reply to	#65025

On Thursday, July 9, 2015 at 9:34:09 AM UTC-7, Richard Heathfield wrote:
> On 09/07/15 17:15, David Kleinecke wrote:
> > On Wednesday, July 8, 2015 at 11:12:57 AM UTC-7, Keith Thompson wrote:
> 
> <snip>
> 
> >> Personally, I find the standard's choices of which behaviors are
> >> undefined vs. unspecified vs. implementation-defined *mostly*
> >> reasonable.  I think you're advocating additional requirements on
> >> all implementations that have insufficient benefit to justify them.
> >
> > You are correct. I want all the "unspecified" behavior documented.
> 
> Keith has already pointed out that this documentation game isn't worth 
> the implementation's candle. There is no benefit in your proposal that I 
> can see. "I want" is sufficient justification for buying a DVD or an 
> ornament for the shelf or a space hopper, but it is not sufficient for 
> changing an international standard. You need to come up with a why.
> 
> > My current hypothesis is that in the earlier drafts of the C90
> > standard all the behavior now called implementation-defined was
> > called "unspecified". That later on the implementation-defined
> > nomenclature was introduced - but not all instances of
> > unspecified were updated.
> 
> Do you have any evidence in favour of this hypothesis? I have some 
> evidence against it. The C90 standard comprised the ANSI C Standard of 
> 1989 and a few extra sections at the beginning for the sake of meeting 
> ISO's documentation standards. So there were no changes between "earlier 
> drafts of the C90 standard" that resulted in a shift from unspecified to 
> implementation-defined behaviour.
> 
> > There are other signs of haste in the
> > standard (eg "sizeof" as an operator).
> 
> As an operator, sizeof works very well. As a function, it would work 
> very badly - it would require properties that no other function has.
> 
> > PS: As I have said elsewhere I object to section 5.2.2 entirely and,
> > as I will say, I think a matter like whether "errno" is a macro is
> > already documented because what errno is is stated in the header
> > <errno.h> which the user can read (in any sane development
> > environment).
> 
> Well, errno is an unusual case. I can only think of two non-conformances 
> of Borland's C compiler, and that's one of them - getting a C program to 
> work with errno under Borland is not easy (in fact, I never managed it). 
> I think errno /is/ poorly specified and poorly designed. But I don't 
> think that requiring the implementation to define whether or not it is a 
> macro would help.
> 
> As for reading headers, one of the most frustrating aspects of gcc is 
> that sometimes one /is/ tempted to peek in the headers, and that's when 
> it turns out that it's not actually possible to find anything (unless, 
> of course, you speak gcc, which I don't).
 
An easy way to look at the headers would seem to be an obvious thing to
provide. But I haven't found them either. I know they're around 
somewhere.

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

#65138

From	James Kuyper <jameskuyper@verizon.net>
Date	2015-07-10 12:54 -0400
Message-ID	<559FF8DC.1040201@verizon.net>
In reply to	#65132

On 07/10/2015 12:24 PM, David Kleinecke wrote:
> On Thursday, July 9, 2015 at 9:34:09 AM UTC-7, Richard Heathfield wrote:
...
>> As for reading headers, one of the most frustrating aspects of gcc is 
>> that sometimes one /is/ tempted to peek in the headers, and that's when 
>> it turns out that it's not actually possible to find anything (unless, 
>> of course, you speak gcc, which I don't).
>  
> An easy way to look at the headers would seem to be an obvious thing to
> provide. But I haven't found them either. I know they're around 
> somewhere.

I just compile a program that #includes the desired header with -E
instead of -c. The output is the entire translation unit after
pre-processing, except that #line directives have been inserted. If you
compile the output with -c, the #line directives have the effect of
ensuring that error messages refer to the correct file name and line
number. Look at the #line directives to find the full path name of the
header files.

I've used this method mainly for tracking down the location of
third-party header files, but it works for the standard headers as well.

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

#65040

From	Keith Thompson <kst-u@mib.org>
Date	2015-07-09 10:58 -0700
Message-ID	<lnzj358b78.fsf@kst-u.example.com>
In reply to	#65021

David Kleinecke <dkleinecke@gmail.com> writes:
> On Wednesday, July 8, 2015 at 11:12:57 AM UTC-7, Keith Thompson wrote:
[...]
>> I get the general impression that you dislike the idea of unspecified
>> behavior that is not implementation-defined, and would prefer it, in
>> some, many, or perhaps all cases, to be implementation-defined behavior
>> (i.e., implementations should be required to document their choices).
>> Is that a fair statement?
>> 
>> Does this apply to *everything* that the standard currently says
>> is unspecified but not implementation-defined?
>> 
>> Personally, I find the standard's choices of which behaviors are
>> undefined vs. unspecified vs. implementation-defined *mostly*
>> reasonable.  I think you're advocating additional requirements on
>> all implementations that have insufficient benefit to justify them.
>  
> You are correct. I want all the "unspecified" behavior documented.

Thank you for the clear statement.

I strongly disagree.

You want to require all implementations to document, for example, "The
order in which subexpressions are evaluated and the order in which side
effects take place, except as specified for the function-call (), &&, ||,
? :, and comma operators (6.5)" (which is currently unspecified).

You want to require all implementations to document "The layout of
storage for function parameters".  You can refer to function parameters
by their names; why do you need to know how they're laid out in memory?

You want to require all implementations to document "The order and
contiguity of storage allocated by successive calls to the calloc,
malloc, and realloc functions."  How long do you think a complete
specification of that would be, and how would it be useful?

> My current hypothesis is that in the earlier drafts of the C90
> standard all the behavior now called implementation-defined was 
> called "unspecified". That later on the implementation-defined
> nomenclature was introduced - but not all instances of
> unspecified were updated.

Do you have any evidence of this?

>                           There are other signs of haste in the
> standard (eg "sizeof" as an operator). 

What else should it be?

> PS: As I have said elsewhere I object to section 5.2.2 entirely and,
> as I will say, I think a matter like whether "errno" is a macro is
> already documented because what errno is is stated in the header
> <errno.h> which the user can read (in any sane development
> environment).

(5.2.2 is "Character display semantics".)

The latter is settled.  The current C standard (C11) requires errno to
be a macro.

The standard does not require headers to be human- readable.  I suppose
you'd want to add that as a requirement.

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

#65133

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-07-10 09:33 -0700
Message-ID	<30dbd9ab-036d-4b2a-bcea-7538f2dbe73d@googlegroups.com>
In reply to	#65040

On Thursday, July 9, 2015 at 10:58:46 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Wednesday, July 8, 2015 at 11:12:57 AM UTC-7, Keith Thompson wrote:
> [...]
> >> I get the general impression that you dislike the idea of unspecified
> >> behavior that is not implementation-defined, and would prefer it, in
> >> some, many, or perhaps all cases, to be implementation-defined behavior
> >> (i.e., implementations should be required to document their choices).
> >> Is that a fair statement?
> >> 
> >> Does this apply to *everything* that the standard currently says
> >> is unspecified but not implementation-defined?
> >> 
> >> Personally, I find the standard's choices of which behaviors are
> >> undefined vs. unspecified vs. implementation-defined *mostly*
> >> reasonable.  I think you're advocating additional requirements on
> >> all implementations that have insufficient benefit to justify them.
> >  
> > You are correct. I want all the "unspecified" behavior documented.
> 
> Thank you for the clear statement.
> 
> I strongly disagree.
> 
> You want to require all implementations to document, for example, "The
> order in which subexpressions are evaluated and the order in which side
> effects take place, except as specified for the function-call (), &&, ||,
> ? :, and comma operators (6.5)" (which is currently unspecified).
> 
> You want to require all implementations to document "The layout of
> storage for function parameters".  You can refer to function parameters
> by their names; why do you need to know how they're laid out in memory?
> 
> You want to require all implementations to document "The order and
> contiguity of storage allocated by successive calls to the calloc,
> malloc, and realloc functions."  How long do you think a complete
> specification of that would be, and how would it be useful?
> 
> > My current hypothesis is that in the earlier drafts of the C90
> > standard all the behavior now called implementation-defined was 
> > called "unspecified". That later on the implementation-defined
> > nomenclature was introduced - but not all instances of
> > unspecified were updated.
> 
> Do you have any evidence of this?
> 
> >                           There are other signs of haste in the
> > standard (eg "sizeof" as an operator). 
> 
> What else should it be?
> 
> > PS: As I have said elsewhere I object to section 5.2.2 entirely and,
> > as I will say, I think a matter like whether "errno" is a macro is
> > already documented because what errno is is stated in the header
> > <errno.h> which the user can read (in any sane development
> > environment).
> 
> (5.2.2 is "Character display semantics".)
> 
> The latter is settled.  The current C standard (C11) requires errno to
> be a macro.
> 
> The standard does not require headers to be human- readable.  I suppose
> you'd want to add that as a requirement.
 
I think you don't understand what I mean by documented. I just want
what may happened stated. All I want for, say, the order of arguments
is that there is a statement in the documentation like "the order
in which the arguments of a function are evaluated is unpredicatable." 
That is useful because an implementation might make them predicatable.
At the moment the documentation is not required to say anything on this
subject.

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

#65179

From	Keith Thompson <kst-u@mib.org>
Date	2015-07-10 12:11 -0700
Message-ID	<ln1tgfsu8i.fsf@kst-u.example.com>
In reply to	#65133

David Kleinecke <dkleinecke@gmail.com> writes:
> On Thursday, July 9, 2015 at 10:58:46 AM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
[...]
>> > You are correct. I want all the "unspecified" behavior documented.
>> 
>> Thank you for the clear statement.
>> 
>> I strongly disagree.

[snip examples]

> I think you don't understand what I mean by documented. I just want
> what may happened stated. All I want for, say, the order of arguments
> is that there is a statement in the documentation like "the order
> in which the arguments of a function are evaluated is unpredicatable." 
> That is useful because an implementation might make them predicatable.
> At the moment the documentation is not required to say anything on this
> subject.

For the order to be truly *unpredictable*, it would have to use some
high-quality random number generator to determine the order on each
call.  Is that really what you meant?

In practice, the order is arbitrary, and may change depending on factors
that are not at all obvious.

I am perfectly satisfied with the standard's statement that the order is
unspecified (and I'm glossing over the possibility that evaluation could
be interleaved, since there are no sequence points between argument
evaluations).

If an implementation documented the order as "unpredictable", how would
you benefit from that information?

If gcc, for example, provided documentation that specified exactly how
the order is determined (for a given release, target platform, and
optimization level), how would you benefit from that information?

If the documentation merely stated that the order is unspecified, would
that satisfy you?  If so, what's the point?  That's exactly what the
standard already says.

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

#65194

From	glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date	2015-07-10 21:05 +0000
Message-ID	<mnpc2n$7tb$1@speranza.aioe.org>
In reply to	#65179

Keith Thompson <kst-u@mib.org> wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
(snip)

>> I think you don't understand what I mean by documented. I just want
>> what may happened stated. All I want for, say, the order of arguments
>> is that there is a statement in the documentation like "the order
>> in which the arguments of a function are evaluated is unpredicatable." 
>> That is useful because an implementation might make them predicatable.
>> At the moment the documentation is not required to say anything on this
>> subject.
 
> For the order to be truly *unpredictable*, it would have to use some
> high-quality random number generator to determine the order on each
> call.  Is that really what you meant?

Interesting question.
 
> In practice, the order is arbitrary, and may change depending 
> on factors that are not at all obvious.

In the case of processors that allow out of order execution, it
seems possible that actual evaluation order is unpredictable,
but it is usual to only do it when the results are predictable.

In the case of variables that should be volatile, but aren't,
it is possible that you could see some unexpected evaluation.

> I am perfectly satisfied with the standard's statement that the order is
> unspecified (and I'm glossing over the possibility that evaluation could
> be interleaved, since there are no sequence points between argument
> evaluations).

In most cases, the compiler chooses, and the standard allows
it to choose. The compiler could even use a random number
generator.  (Maybe even one depending on natural randomness.)
 
> If an implementation documented the order as "unpredictable", 
> how would you benefit from that information?

OK, say you do (and I know you aren't supposed to):

   for(i=j=0;j<10;j++) y[j]=x(i++, i++, i++);

should x find the relative values of its arguements
consistent, or not?

   function x(int k, int l, int m) {
      return (k>l)+2*(l>m)+4*(k>m);
      }

> If gcc, for example, provided documentation that specified exactly how
> the order is determined (for a given release, target platform, and
> optimization level), how would you benefit from that information?
 
> If the documentation merely stated that the order is unspecified, would
> that satisfy you?  If so, what's the point?  That's exactly what the
> standard already says.

-- glen

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

#65204

From	Keith Thompson <kst-u@mib.org>
Date	2015-07-10 17:14 -0700
Message-ID	<ln8uanr1nc.fsf@kst-u.example.com>
In reply to	#65194

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
> (snip)
>
>>> I think you don't understand what I mean by documented. I just want
>>> what may happened stated. All I want for, say, the order of arguments
>>> is that there is a statement in the documentation like "the order
>>> in which the arguments of a function are evaluated is unpredicatable." 
>>> That is useful because an implementation might make them predicatable.
>>> At the moment the documentation is not required to say anything on this
>>> subject.
>  
>> For the order to be truly *unpredictable*, it would have to use some
>> high-quality random number generator to determine the order on each
>> call.  Is that really what you meant?
>
> Interesting question.

That depends on what David's answer is.

[...]

>> If an implementation documented the order as "unpredictable", 
>> how would you benefit from that information?
>
> OK, say you do (and I know you aren't supposed to):
>
>    for(i=j=0;j<10;j++) y[j]=x(i++, i++, i++);
>
> should x find the relative values of its arguements
> consistent, or not?

The behavior is undefined; I don't care how it actually behaves.
(So far we're just talking about changing unspecified behavior into
implementation-defined 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]

#65306

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-07-11 09:32 -0700
Message-ID	<29d47a6f-6474-40dd-86f3-152022086b0a@googlegroups.com>
In reply to	#65204

On Friday, July 10, 2015 at 5:14:40 PM UTC-7, Keith Thompson wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> > Keith Thompson <kst-u@mib.org> wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> > (snip)
> >
> >>> I think you don't understand what I mean by documented. I just want
> >>> what may happened stated. All I want for, say, the order of arguments
> >>> is that there is a statement in the documentation like "the order
> >>> in which the arguments of a function are evaluated is unpredicatable." 
> >>> That is useful because an implementation might make them predicatable.
> >>> At the moment the documentation is not required to say anything on this
> >>> subject.
> >  
> >> For the order to be truly *unpredictable*, it would have to use some
> >> high-quality random number generator to determine the order on each
> >> call.  Is that really what you meant?
> >
> > Interesting question.
> 
> That depends on what David's answer is.
 
I didn't answer that. I was using "unpredicable" in the sense that
the programmer is not going to be able to predict it. Why get all
technical about it?

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

#65311

From	James Kuyper <jameskuyper@verizon.net>
Date	2015-07-11 12:59 -0400
Message-ID	<55A14B81.2060106@verizon.net>
In reply to	#65306

On 07/11/2015 12:32 PM, David Kleinecke wrote:
> On Friday, July 10, 2015 at 5:14:40 PM UTC-7, Keith Thompson wrote:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> wrote:
...
>>>> For the order to be truly *unpredictable*, it would have to use some
>>>> high-quality random number generator to determine the order on each
>>>> call.  Is that really what you meant?
>>>
>>> Interesting question.
>>
>> That depends on what David's answer is.
>  
> I didn't answer that. I was using "unpredicable" in the sense that
> the programmer is not going to be able to predict it. Why get all
> technical about it?

Well, "unspecified" also means that the programmer is not going to be
able to predict it. So what's your objection to using a term that
exactly states the correct issue (a lack of specification) rather than
obfuscating the issue by incorrectly implying that it's due to innate
unpredictability?

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

#65375

From	Keith Thompson <kst-u@mib.org>
Date	2015-07-11 17:21 -0700
Message-ID	<lnoajins3x.fsf@kst-u.example.com>
In reply to	#65306

David Kleinecke <dkleinecke@gmail.com> writes:
> On Friday, July 10, 2015 at 5:14:40 PM UTC-7, Keith Thompson wrote:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> > Keith Thompson <kst-u@mib.org> wrote:
>> >> David Kleinecke <dkleinecke@gmail.com> writes:
>> > (snip)
>> >
>> >>> I think you don't understand what I mean by documented. I just want
>> >>> what may happened stated. All I want for, say, the order of arguments
>> >>> is that there is a statement in the documentation like "the order
>> >>> in which the arguments of a function are evaluated is unpredicatable." 
>> >>> That is useful because an implementation might make them predicatable.
>> >>> At the moment the documentation is not required to say anything on this
>> >>> subject.
>> >  
>> >> For the order to be truly *unpredictable*, it would have to use some
>> >> high-quality random number generator to determine the order on each
>> >> call.  Is that really what you meant?
>> >
>> > Interesting question.
>> 
>> That depends on what David's answer is.
>  
> I didn't answer that. I was using "unpredicable" in the sense that
> the programmer is not going to be able to predict it. Why get all
> technical about it?

Um, because we're discussing technical issues.  Or at least I am.

Your use of "unpredictable" was confusing.  You could have clarified
what you meant when I asked.

From my perspective, you seem to be uninterested in communicating
clearly.  I'm about ready to give up on this.

-- 
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 1 of 7 [1] 2 3 4 5 6 7 Next page →

csiph-web

Unspecified behavior in C

Contents

#64878 — Unspecified behavior in C

#64883

#64914

#64918

#64938

#64944

#64947

#64951

#65021

#65025

#65132

#65138

#65040

#65133

#65179

#65194

#65204

#65306

#65311

#65375