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

#65593

From	Öö Tiib <ootiib@hot.ee>
Date	2015-07-14 15:54 -0700
Message-ID	<dfcdc72c-d0d0-447f-9ca0-012b965e2362@googlegroups.com>
In reply to	#65587

On Tuesday, 14 July 2015 23:30:59 UTC+3, James Kuyper  wrote:
> On 07/14/2015 04:12 PM, Öö Tiib wrote:
> ...
> > Compiler may perhaps order initialization of non-volatile static
> > variables how it sees fit since observable behavior that the 
> > program describes will stay same.
> > 
> > However doesn't initialization of static storage duration volatile
> > qualified variables mean side effects? Perhaps it is said somewhere
> > that initialization of those does not mean side effects. Otherwise
> > it would be nice if standard said something about order of such
> > side effects.
> 
> "Accessing a volatile object, modifying an object, modifying a file, or
> calling a function that does any of those operations are all _side
> effects_, ..." (5.1.2.3p2).
> 
> The phrase "side effects" is italicized, and ISO convention indicating
> that this sentence is the official definition of that phrase. Notice
> that it is only accessing a volatile object that is relevant.
> 
> "What constitutes an access to an object that has volatile-qualified
> type is implementation-defined." (6.7.3p7)
> 
> Therefore, whether or not initialization of a volatile-qualified object
> with static storage duration counts as accessing it must be defined by
> the implementation.
> Even if an implementation did document the order of initialization of
> such objects, I'm not sure what use could be made of that information.
> Could you give an example?

For example when doing something entirely low level and platform-specific
what volatile is meant for. Dealing with some memory-mapped peripheral
registers or the like. If it can cause problems to reset those in wrong
order at program start and there are no way to find out or control the
order then we have to use pointers to volatile despite using static
volatile variables for such registers can be otherwise more elegant
or convenient.

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

#65600

From	Morris Dovey <mrdovey@iedu.com>
Date	2015-07-14 21:41 -0500
Message-ID	<mo4h8j$hnl$1@speranza.aioe.org>
In reply to	#65593

On 7/14/15 5:54 PM, Öö Tiib wrote:

> For example when doing something entirely low level and platform-specific
> what volatile is meant for. Dealing with some memory-mapped peripheral
> registers or the like. If it can cause problems to reset those in wrong
> order at program start and there are no way to find out or control the
> order then we have to use pointers to volatile despite using static
> volatile variables for such registers can be otherwise more elegant
> or convenient.

I don't think your elegance/convenience arguments don't hold up very 
well in practice.

If what you want to code is

    volatile unsigned char ioreg @ address;

    ioreg = output_value;

with no @address capability, you can get there with a macro

    #define ioreg (*(volatile unsigned char *)(ioptr))

    unsigned char *ioptr = address;

    ioreg = output_value;

which provides identical function, elegance, and convenience.

-- 
Morris Dovey
http://www.iedu.com/Solar

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

#65601

From	Morris Dovey <mrdovey@iedu.com>
Date	2015-07-14 21:51 -0500
Message-ID	<mo4hr4$ikn$1@speranza.aioe.org>
In reply to	#65600

On 7/14/15 9:41 PM, Morris Dovey wrote:
> On 7/14/15 5:54 PM, Öö Tiib wrote:
>
>> For example when doing something entirely low level and platform-specific
>> what volatile is meant for. Dealing with some memory-mapped peripheral
>> registers or the like. If it can cause problems to reset those in wrong
>> order at program start and there are no way to find out or control the
>> order then we have to use pointers to volatile despite using static
>> volatile variables for such registers can be otherwise more elegant
>> or convenient.
>
> I don't think your elegance/convenience arguments hold up very
> well in practice.
>
> If what you want to code is
>
>     volatile unsigned char ioreg @ address;
>
>     ioreg = output_value;
>
> with no @address capability, you can get there with a macro
>
>     #define ioreg (*(volatile unsigned char *)(ioptr))
>
>     unsigned char *ioptr = address;
>
>     ioreg = output_value;
>
> which provides identical function, elegance, and convenience.

I suppose that could've been simplified to

    #define ioreg (*(volatile unsigned char *)(address))

    ioreg = output_value;

:-P

-- 
Morris Dovey
http://www.iedu.com/Solar

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

#65650

From	Öö Tiib <ootiib@hot.ee>
Date	2015-07-15 12:42 -0700
Message-ID	<01e7dc4d-dece-40d4-ac71-0b2ca9b79f64@googlegroups.com>
In reply to	#65601

On Wednesday, 15 July 2015 05:51:26 UTC+3, Morris Dovey  wrote:
> On 7/14/15 9:41 PM, Morris Dovey wrote:
> > On 7/14/15 5:54 PM, Öö Tiib wrote:
> >
> >> For example when doing something entirely low level and platform-specific
> >> what volatile is meant for. Dealing with some memory-mapped peripheral
> >> registers or the like. If it can cause problems to reset those in wrong
> >> order at program start and there are no way to find out or control the
> >> order then we have to use pointers to volatile despite using static
> >> volatile variables for such registers can be otherwise more elegant
> >> or convenient.
> >
> > I don't think your elegance/convenience arguments hold up very
> > well in practice.
> >
> > If what you want to code is
> >
> >     volatile unsigned char ioreg @ address;
> >
> >     ioreg = output_value;

It may be achieved with attribute or pragma or linker option. 

> >
> > with no @address capability, you can get there with a macro
> >
> >     #define ioreg (*(volatile unsigned char *)(ioptr))
> >
> >     unsigned char *ioptr = address;
> >
> >     ioreg = output_value;
> >
> > which provides identical function, elegance, and convenience.
> 
> I suppose that could've been simplified to
> 
>     #define ioreg (*(volatile unsigned char *)(address))
> 
>     ioreg = output_value;
> 
> :-P

Some minor things only that such 'ioreg' does not respect scopes and
that 'address' must have same value everywhere where 'ioreg' is used
and that it has to be dynamically initialized after entry point.
Such macroness issues are typically mitigated by capitalizing those
names.

Otherwise it is perhaps good replacement to volatile with static
storage duration.

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

#65659

From	Morris Dovey <mrdovey@iedu.com>
Date	2015-07-15 16:13 -0500
Message-ID	<mo6iej$ad$1@speranza.aioe.org>
In reply to	#65650

On 7/15/15 2:42 PM, Öö Tiib wrote:
> On Wednesday, 15 July 2015 05:51:26 UTC+3, Morris Dovey  wrote:

>>      #define ioreg (*(volatile unsigned char *)(address))
>>
>>      ioreg = output_value;


> Some minor things only that such 'ioreg' does not respect scopes and
> that 'address' must have same value everywhere where 'ioreg' is used
> and that it has to be dynamically initialized after entry point.

Yes, the macro would have file scope unless the programmer chose to 
#undef it, although I can't recall that ever being a problem.

The alternative to dynamic initialization, of course, to specify the 
actual memory-mapped address in the macro definition, as in

    #define UART_A_TxD (*(volatile unsigned char *)(0xDEADC0DE))

> Such macroness issues are typically mitigated by capitalizing those
> names.

That's very interesting. :-)

> Otherwise it is perhaps good replacement to volatile with static
> storage duration.

I agree, and personally appreciate that [1] it already works well with 
no change to the language and [2] it doesn't require _any_ memory 
variables be allocated.

-- 
Morris Dovey
http://www.iedu.com/Solar

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

#65700

From	Morris Dovey <mrdovey@iedu.com>
Date	2015-07-16 08:49 -0500
Message-ID	<mo8cp9$n8s$1@speranza.aioe.org>
In reply to	#65650

On 7/15/15 2:42 PM, Öö Tiib wrote:

> Some minor things only that such 'ioreg' does not respect scopes and
> that 'address' must have same value everywhere where 'ioreg' is used
> and that it has to be dynamically initialized after entry point.
> Such macroness issues are typically mitigated by capitalizing those
> names.
>
> Otherwise it is perhaps good replacement to volatile with static
> storage duration.

Snapshot from an old "real life" SOC development test suite...

System-wide I/O header file (included by each I/O driver-specific header 
file):

http://www.iedu.com/tmp/mips_io_h.png

Ethernet driver header file (partial, but enough so that you'll be able 
to catch the concept):

http://www.iedu.com/tmp/eth_h.png

The rationale is provided in the header comments. No memory was consumed 
in setting up I/O addressing, and none of the "ugly" appeared in the 
driver source code. :-)

-- 
Morris Dovey
http://www.iedu.com/Solar

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

#66023

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2015-07-20 10:10 -0700
Message-ID	<kfnbnf6n4b8.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#65700

Morris Dovey <mrdovey@iedu.com> writes:

[snip]
>
> Snapshot from an old "real life" SOC development test suite...
>
> System-wide I/O header file (included by each I/O driver-specific
> header file):
>
> http://www.iedu.com/tmp/mips_io_h.png

I suggest again that it is better to post text than images
for source code.  Following a link is okay even if not my
first choice, but having the result be an image rather than
text makes it essentially impossible to read the source in
any careful way.

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

#66039

From	Morris Dovey <mrdovey@iedu.com>
Date	2015-07-20 13:24 -0500
Message-ID	<mojedf$inb$1@speranza.aioe.org>
In reply to	#66023

On 7/20/15 12:10 PM, Tim Rentsch wrote:

> Morris Dovey <mrdovey@iedu.com> writes:
>
> [snip]
>>
>> Snapshot from an old "real life" SOC development test suite...
>>
>> System-wide I/O header file (included by each I/O driver-specific
>> header file):
>>
>> http://www.iedu.com/tmp/mips_io_h.png
>
> I suggest again that it is better to post text than images for source
> code.  Following a link is okay even if not my first choice, but
> having the result be an image rather than text makes it essentially
> impossible to read the source in any careful way.

Your suggestion was read, duly considered, and not applied in this case
(although it has been in intervening posts) for reasons sufficient to
myself.

I regret that the png image format makes it impossible for you to read
the source in any careful way.

-- 
Morris Dovey
http://www.iedu.com/Solar

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

#66239

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2015-07-23 02:56 -0700
Message-ID	<kfntwsvi4eh.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#66039

Morris Dovey <mrdovey@iedu.com> writes:

> On 7/20/15 12:10 PM, Tim Rentsch wrote:
>
>> Morris Dovey <mrdovey@iedu.com> writes:
>>
>> [snip]
>>
>>> Snapshot from an old "real life" SOC development test suite...
>>>
>>> System-wide I/O header file (included by each I/O driver-specific
>>> header file):
>>>
>>> http://www.iedu.com/tmp/mips_io_h.png
>>
>> I suggest again that it is better to post text than images for source
>> code.  Following a link is okay even if not my first choice, but
>> having the result be an image rather than text makes it essentially
>> impossible to read the source in any careful way.
>
> Your suggestion was read, duly considered, and not applied in this
> case (although it has been in intervening posts) for reasons
> sufficient to myself.

Yes, I thought that might be so (and I did notice the intervening
cases, and appreciate you doing that).

> I regret that the png image format makes it impossible for you to
> read the source in any careful way.

Me too, especially since I often find what you have to say
sufficiently interesting to be worth reading.

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

#66258

From	Morris Dovey <mrdovey@iedu.com>
Date	2015-07-23 11:26 -0500
Message-ID	<mor4ir$lqc$1@speranza.aioe.org>
In reply to	#66239

On 7/23/15 4:56 AM, Tim Rentsch wrote:
> Morris Dovey <mrdovey@iedu.com> writes:
>
>> On 7/20/15 12:10 PM, Tim Rentsch wrote:
>>
>>> Morris Dovey <mrdovey@iedu.com> writes:
>>>
>>> [snip]
>>>
>>>> Snapshot from an old "real life" SOC development test suite...
>>>>
>>>> System-wide I/O header file (included by each I/O
>>>> driver-specific header file):
>>>>
>>>> http://www.iedu.com/tmp/mips_io_h.png
>>>
>>> I suggest again that it is better to post text than images for
>>> source code.  Following a link is okay even if not my first
>>> choice, but having the result be an image rather than text makes
>>>  it essentially impossible to read the source in any careful
>>> way.
>>
>> Your suggestion was read, duly considered, and not applied in this
>> case (although it has been in intervening posts) for reasons
>> sufficient to myself.
>
> Yes, I thought that might be so (and I did notice the intervening
> cases, and appreciate you doing that).
>
>> I regret that the png image format makes it impossible for you to
>> read the source in any careful way.
>
> Me too, especially since I often find what you have to say
> sufficiently interesting to be worth reading.

I suspect you didn’t miss anything new (to you) or particularly interesting.

The first file (mips_io.h) defines four groups of macros. For
background, all registers for each device are at fixed displacements
from a device "base" address (Has to do with economical address decoding
logic and portability of logic blocks)

The first group of four macros establishes the size of each device's I/F
registers as and defines the structure of what I wanted to have as a result.

The second group of nineteen macros defines a macro for the "base"
address of each of the on-chip devices. The rationale for breaking these
out involved maximizing portability of headers for other/future SOCs. It
wasn't something the client had asked for, but it was easy for me to
provide, and they liked the re-use possibilities.

The third group of nineteen macros uses the already defined macros to
produce an easy-to-use macro to produce pointers to specified registers
at compile time. (not relevant to this discussion)

The fourth group of three macros provided the ability to extract a bit
field from a 32-bit value (kinda like MID$() at the bit level) and the
ability to produce a 32-bit mask from high and low bit numbers. These
were included in the top-level header to make them available for use in
all driver sources.

The second file (eth.h) provides example macro definitions specific to
the ethernet logic, and uses the eth(r) macro from the first file to
produce addressing for all twenty-nine of the device registers.

The remainder of the second file is used to provide definition of the
structure of the various registers' data and isn't relevant to this
discussion.

Extracting from both files for just one ethernet register:

    #define IOi_(b,r) (*(volatile unsigned int *)(b+(unsigned)(r))
    #define eth_      0xA0031000u    /* Base address           */
    #define eth(r)    IOi_(eth_,(r)) /* Any ethernet register  */
    #define ETH_TXBA  eth(0x0400)    /* Tx buffer A start addr */

Which results in:

    #define ETH_TXBA (*(volatile unsigned *)(0xA0031400u))

So that to set the the transmit buffer address register in the driver
function, it's sufficient to code:

    ETH_TXBA = /* Pointer to transmit data */ ;

HTH :-)

-- 
Morris Dovey
http://www.iedu.com/Solar

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

#66412

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2015-07-26 11:24 -0700
Message-ID	<kfn380ag4k1.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#66258

Morris Dovey <mrdovey@iedu.com> writes:

> On 7/23/15 4:56 AM, Tim Rentsch wrote:
>> Morris Dovey <mrdovey@iedu.com> writes:
>>
>>> On 7/20/15 12:10 PM, Tim Rentsch wrote:
>>>
>>>> Morris Dovey <mrdovey@iedu.com> writes:
>>>>
>>>> [snip]
>>>>
>>>>> Snapshot from an old "real life" SOC development test suite...
>>>>>
>>>>> System-wide I/O header file (included by each I/O
>>>>> driver-specific header file):
>>>>>
>>>>> http://www.iedu.com/tmp/mips_io_h.png
>>>>
>>>> I suggest again that it is better to post text than images for
>>>> source code.  Following a link is okay even if not my first
>>>> choice, but having the result be an image rather than text makes
>>>>  it essentially impossible to read the source in any careful
>>>> way.
>>>
>>> Your suggestion was read, duly considered, and not applied in this
>>> case (although it has been in intervening posts) for reasons
>>> sufficient to myself.
>>
>> Yes, I thought that might be so (and I did notice the intervening
>> cases, and appreciate you doing that).
>>
>>> I regret that the png image format makes it impossible for you to
>>> read the source in any careful way.
>>
>> Me too, especially since I often find what you have to say
>> sufficiently interesting to be worth reading.
>
> I suspect you didn?t miss anything new (to you) or particularly
> interesting.
>
> The first file (mips_io.h) defines four groups of macros.
> [snip rest of description]

It's hard to relate this to the previous context without more
of the actual code.  But thank you for taking the time to
post it.

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

#66270

From	Morris Dovey <mrdovey@iedu.com>
Date	2015-07-23 19:03 -0500
Message-ID	<morvcm$j65$1@speranza.aioe.org>
In reply to	#66239

On 7/23/15 4:56 AM, Tim Rentsch wrote:
> Morris Dovey <mrdovey@iedu.com> writes:
>
>> On 7/20/15 12:10 PM, Tim Rentsch wrote:
>>
>>> Morris Dovey <mrdovey@iedu.com> writes:
>>>
>>> [snip]
>>>
>>>> Snapshot from an old "real life" SOC development test suite...
>>>>
>>>> System-wide I/O header file (included by each I/O driver-specific
>>>> header file):
>>>>
>>>> http://www.iedu.com/tmp/mips_io_h.png
>>>
>>> I suggest again that it is better to post text than images for source
>>> code.  Following a link is okay even if not my first choice, but
>>> having the result be an image rather than text makes it essentially
>>> impossible to read the source in any careful way.
>>
>> Your suggestion was read, duly considered, and not applied in this
>> case (although it has been in intervening posts) for reasons
>> sufficient to myself.
>
> Yes, I thought that might be so (and I did notice the intervening
> cases, and appreciate you doing that).
>
>> I regret that the png image format makes it impossible for you to
>> read the source in any careful way.
>
> Me too, especially since I often find what you have to say
> sufficiently interesting to be worth reading.

I suspect you didn’t miss anything new (to you) or particularly interesting.

The first file (mips_io.h) defines four groups of macros. For
background, all registers for each device are at fixed displacements
from a device "base" address (Has to do with economical address decoding
logic and portability of logic blocks)

The first group of four macros establishes the size of each device's I/F
registers as and defines the structure of what I wanted to have as a result.

The second group of nineteen macros defines a macro for the "base"
address of each of the on-chip devices. The rationale for breaking these
out involved maximizing portability of headers for other/future SOCs. It
wasn't something the client had asked for, but it was easy for me to
provide, and they liked the re-use possibilities.

The third group of nineteen macros uses the already defined macros to
produce an easy-to-use macro to produce pointers to specified registers
at compile time.

The fourth group of three macros provided the ability to extract a bit
field from a 32-bit value (kinda like MID$() at the bit level) and the
ability to produce a 32-bit mask from high and low bit numbers. These
were included in the top-level header to make them available for use in
all driver sources. (not relevant to this discussion)

The second file (eth.h) provides example macro definitions specific to
the ethernet logic, and uses the eth(r) macro from the first file to
produce addressing for all twenty-nine of the device registers.

The remainder of the second file is used to provide definition of the
structure of the various registers' data and isn't relevant to this
discussion.

Extracting from both files for just one ethernet register:

    #define IOi_(b,r) (*(volatile unsigned int *)(b+(unsigned)(r))
    #define eth_      0xA0031000u    /* Base address           */
    #define eth(r)    IOi_(eth_,(r)) /* Any ethernet register  */
    #define ETH_TXBA  eth(0x0400)    /* Tx buffer A start addr */

Which results in:

    #define ETH_TXBA (*(volatile unsigned *)(0xA0031400u))

So that to set the the transmit buffer address register in the driver
function, it's sufficient to code:

    ETH_TXBA = /* Pointer to transmit data */ ;

HTH :-)

-- 
Morris Dovey
http://www.iedu.com/Solar

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

#65679

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-07-15 21:19 -0700
Message-ID	<1622f824-7bca-4214-8768-86abf1c5d867@googlegroups.com>
In reply to	#65579

On Tuesday, July 14, 2015 at 11:57:50 AM UTC-7, James Kuyper wrote:
> On 07/14/2015 12:29 PM, James Kuyper wrote:
> > On 07/14/2015 12:16 PM, David Kleinecke wrote:
> > ...
> >> OK. I admit that it never occurred to me that anyone would object
> >> to better documentation as a goal.
> > 
> > We don't. We object to making documentation worse by including in it
> > things that don't need to be documented, and which might make the
> > documentation unreadably complicated and unacceptably difficult to create.
> 
> Note, in particular, that we're willing to consider the possibility that
> we're wrong about any particular items not needing to be documented.
> We're willing to listen to your explanation why documenting these things
> would make the documentation better (as opposed to merely bigger). I
> can't guarantee that we'll agree when we've heard your reasons - but
> we'll never have even a chance of learning that we were wrong unless you
> articulate your reasons - and we've repeatedly requested that you give
> us that chance.

And I have repeatedly said my reason is that I want everything 
documented and you wont accept that as a reason. You have not
stated any clearer opposition to that principle other than that 
it is too much trouble.  
 
> Realistically, the fact that you've repeatedly refused the request, the
> fact that you don't even seem to understand the request, creates the
> strong suspicion that you are incapable of articulating a reason. 

You don't seem to recognize a reason when you see one. 

> If you could, you would probably already have done so. You seem so firmly
> convinced that no justification is needed for any documentation, that
> you've probably never even thought about what a proper argument
> justifying such a requirement would look like. Nonetheless, should you
> ever manage to come up with such an argument, I encourage you to present
> it. We'll probably find it full of holes, but I think that all of us
> will learn something from the process.
> 
> Let's put it this way: I insist that you provide full documentation of
> how you spent the past week. More documentation is always better, right?
> So you should have no objection to providing it - but of course, I'm
> pretty sure that you would object. Even if nothing happened last week
> that you would consider private, I'm sure you'd at least object to doing
> the work required to put that documentation together - if you don't have
> anything better to do with your time, you must be pretty bored.
> 
> What kind of argument would your want me to give you, in order to
> convince you to produce such documentation? There certainly are
> arguments that I could present you to justify such a request (for
> instance, you could be a suspect in a criminal investigation, and I
> could be a policeman with relevant jurisdiction). After thinking about
> that for awhile, maybe you'll have a better idea how to present an
> argument why the things the standard says are unspecified should be
> documented.

This is a tempest in a teapot. 

I believe that the purpose of the kind of documentation I believe is
needed is to describe what one can expect a machine (in the abstract
sense - a comiler to be exact) to do. Your attempt to compare that with
a what I would call a log of events is laughable.

If we want a clear debate let us try this:

   Resolved a C compiler shall document what is does to a source
   program in every detail including cases where more than one
   outcome is possible. 

I visualize myself as FOR and you as AGAINST.

Now it is your turn.

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

#65681

From	Martin Shobe <martin.shobe@yahoo.com>
Date	2015-07-15 23:45 -0500
Message-ID	<mo7cpm$1kj$1@dont-email.me>
In reply to	#65679

On 7/15/2015 11:19 PM, David Kleinecke wrote:
> On Tuesday, July 14, 2015 at 11:57:50 AM UTC-7, James Kuyper wrote:
>> On 07/14/2015 12:29 PM, James Kuyper wrote:
>>> On 07/14/2015 12:16 PM, David Kleinecke wrote:
> If we want a clear debate let us try this:
>
>     Resolved a C compiler shall document what is does to a source
>     program in every detail including cases where more than one
>     outcome is possible.
>
> I visualize myself as FOR and you as AGAINST.

There are costs to doing that, what's the benefit?

Martin Shobe

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

#65684

From	James Kuyper <jameskuyper@verizon.net>
Date	2015-07-16 01:37 -0400
Message-ID	<mo7fsd$8q2$1@dont-email.me>
In reply to	#65679

On 07/16/2015 12:19 AM, David Kleinecke wrote:
> On Tuesday, July 14, 2015 at 11:57:50 AM UTC-7, James Kuyper wrote:
...
>> Note, in particular, that we're willing to consider the possibility that
>> we're wrong about any particular items not needing to be documented.
>> We're willing to listen to your explanation why documenting these things
>> would make the documentation better (as opposed to merely bigger). I
>> can't guarantee that we'll agree when we've heard your reasons - but
>> we'll never have even a chance of learning that we were wrong unless you
>> articulate your reasons - and we've repeatedly requested that you give
>> us that chance.
> 
> And I have repeatedly said my reason is that I want everything 
> documented and you wont accept that as a reason.

It isn't. I want you to give me $200,000. Is that a reason for you to
give me that amount of money?

> ... You have not
> stated any clearer opposition to that principle other than that 
> it is too much trouble.  

The burden of proof lies on the the person proposing a change. Once
you've given a reason, we can discuss that further. You've proposed
making everything that's currently unspecified implementation-defined.
That either requires a very impressive general argument, or a large
number of less impressive arguments, one targeting each item that's
currently unspecified.

Despite the vagueness of your reasons, we have made some specific
comments why it's likely to be a bad idea. Many of the things currently
left unspecified were deliberately chosen to be unspecified because
specifying them would be far too complicated, and provide far too little
benefit. That's particularly true of the items from section that

...
>> Realistically, the fact that you've repeatedly refused the request, the
>> fact that you don't even seem to understand the request, creates the
>> strong suspicion that you are incapable of articulating a reason. 
> 
> You don't seem to recognize a reason when you see one.

"I want it documented" is not a reason deserving of attention, unless
you happen to be a dictator who has an army who can shoot anyone who
doesn't give you what you want. In that case, the appropriate attention
to be paid such a reason is to relieve you of that army, by lethal
force, if necessary.

You've provided no other reason that I can recall - so if you have
actually provided some other more compelling reason, you're right - I
didn't recognize it. Would you care to repeat it, clearly labeling it as
a reason, so there's no danger of me not recognizing it?

...
> I believe that the purpose of the kind of documentation I believe is
> needed is to describe what one can expect a machine (in the abstract
> sense - a comiler to be exact) to do.

That's already provided:

1. When the behavior is defined by the standard, you can expect it do
what the standard says.

2. When the behavior is implementation-defined, there's a list of
options provided by the standard, and you can expect the
implementation's documentation to tell you which of those options to
expect a program to choose when using that implementation.

3. When the behavior is merely unspecified, there's a list of options
provided by the standard. and you can expect that one of those options
will be chosen - you can NOT expect that any particular option will be
chosen. If you think that you need to know which option has been chosen,
there's something seriously wrong with the way you're thinking about
your C code - these things were left unspecified precisely because, in
the judgment of the C committee, you don't need to know them. If one of
the unspecified options is one that you don't want to have happen in
your code, re-write it so that it is no longer unspecified.

4. When the standard says that at least one diagnostic is required, you
can expect one diagnostic. You might get more than one, but all you're
entitled to expect is one. An implementation is required to document the
methods you can use to identify diagnostics, so you can expect to find
such a description in the documentation, and you can expect that any
diagnostics generated will match that description. The standard says
nothing else about the contents of the diagnostic message, so you're not
entitled to have expectations about that, either.

Note: while these issues are outside the scope of the standard, there's
no reason you have to actually tolerate situations where an
implementation provides inadequate diagnostics - you have a right as a
consumer of to insist on useful diagnostic messages - but it's not the C
standard which gives you that right, it's the money you're paying for
the compiler. If you're getting the compiler for free, you have less
leverage, so I'd recommend being polite when complaining about
inadequate diagnostics.

An implementation is not required to continue translating a program
after issuing a mandatory diagnostic, but it is allowed to do so. You're
not required to execute the resulting program, but you're allowed to do
so. If you do, the behavior will be undefined - see the next item.

5. When the behavior is undefined, you can't expect particular thing. If
there's any particular thing you don't want your program to do, it's
guaranteed to be one of the things permitted by "undefined behavior".
Therefore, your proper response to finding out that the behavior is
undefined is to change your code so that's no longer the case.
Exception: "undefined behavior", in the C standard, means that the C
standard imposes no requirements on the behavior. If some other document
does impose requirements, that's still "undefined behavior" as far as
the C standard is concerned. If you're willing to restrict the
portability of your code to platforms where that other document is
applicable, then you can expect the behavior of your program to conform
those requirements - not because the C standard says so, but because
that other document says so.

> ... Your attempt to compare that with
> a what I would call a log of events is laughable.

I'm not sure what it is that you're saying you would call "a log of
events". I don't recall talking about anything that could reasonably be
described that way, certainly not in the message you were responding to.
Would you care to explain that comment?

> If we want a clear debate let us try this:
> 
>    Resolved a C compiler shall document what is does to a source
>    program in every detail including cases where more than one
>    outcome is possible. 
> 
> I visualize myself as FOR and you as AGAINST.
> 
> Now it is your turn.

As the person proposing a change, you're supposed to go first.
-- 
James Kuyper

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

#65688

From	Richard Heathfield <rjh@cpax.org.uk>
Date	2015-07-16 09:42 +0100
Message-ID	<mo7qmm$5t0$1@dont-email.me>
In reply to	#65679

On 16/07/15 05:19, David Kleinecke wrote:
> On Tuesday, July 14, 2015 at 11:57:50 AM UTC-7, James Kuyper wrote:
>> On 07/14/2015 12:29 PM, James Kuyper wrote:
>> > On 07/14/2015 12:16 PM, David Kleinecke wrote:
>> > ...
>> >> OK. I admit that it never occurred to me that anyone would object
>> >> to better documentation as a goal.
>> >
>> > We don't. We object to making documentation worse by including in it
>> > things that don't need to be documented, and which might make the
>> > documentation unreadably complicated and unacceptably difficult to create.
>>
>> Note, in particular, that we're willing to consider the possibility that
>> we're wrong about any particular items not needing to be documented.
>> We're willing to listen to your explanation why documenting these things
>> would make the documentation better (as opposed to merely bigger). I
>> can't guarantee that we'll agree when we've heard your reasons - but
>> we'll never have even a chance of learning that we were wrong unless you
>> articulate your reasons - and we've repeatedly requested that you give
>> us that chance.
>
> And I have repeatedly said my reason is that I want everything
> documented and you wont accept that as a reason.

No, that's right, we won't. "I want" is a good enough reason for the 
occasional chocolate or a cup of coffee or a walk around the park, but 
it isn't a good enough reason to persuade a good many people to give up 
a lot of time re-wording the International Standard that governs the 
language, followed by a lot more people giving up a lot more time 
bringing their implementations into line. No, for all that to happen you 
have to be *persuasive*. "I want" doesn't cut it.

> You have not
> stated any clearer opposition to that principle other than that
> it is too much trouble.

Here are some reasons why what you want shouldn't happen:

* It will cost money (with no compensating advantage);
* It will cost time (with no compensating advantage);
* We're good with what we've got already - it works just fine.

Your reasons have to be better, stronger, more powerful, than those 
reasons - and "it will cost money" is a very powerful reason indeed.

<snip>

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

#65730

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-07-16 17:05 -0700
Message-ID	<64413a2c-f5fb-4bde-bfb6-166bb42143d7@googlegroups.com>
In reply to	#65688

On Thursday, July 16, 2015 at 1:42:30 AM UTC-7, Richard Heathfield wrote:
> On 16/07/15 05:19, David Kleinecke wrote:
> > On Tuesday, July 14, 2015 at 11:57:50 AM UTC-7, James Kuyper wrote:
> >> On 07/14/2015 12:29 PM, James Kuyper wrote:
> >> > On 07/14/2015 12:16 PM, David Kleinecke wrote:
> >> > ...
> >> >> OK. I admit that it never occurred to me that anyone would object
> >> >> to better documentation as a goal.
> >> >
> >> > We don't. We object to making documentation worse by including in it
> >> > things that don't need to be documented, and which might make the
> >> > documentation unreadably complicated and unacceptably difficult to create.
> >>
> >> Note, in particular, that we're willing to consider the possibility that
> >> we're wrong about any particular items not needing to be documented.
> >> We're willing to listen to your explanation why documenting these things
> >> would make the documentation better (as opposed to merely bigger). I
> >> can't guarantee that we'll agree when we've heard your reasons - but
> >> we'll never have even a chance of learning that we were wrong unless you
> >> articulate your reasons - and we've repeatedly requested that you give
> >> us that chance.
> >
> > And I have repeatedly said my reason is that I want everything
> > documented and you wont accept that as a reason.
> 
> No, that's right, we won't. "I want" is a good enough reason for the 
> occasional chocolate or a cup of coffee or a walk around the park, but 
> it isn't a good enough reason to persuade a good many people to give up 
> a lot of time re-wording the International Standard that governs the 
> language, followed by a lot more people giving up a lot more time 
> bringing their implementations into line. No, for all that to happen you 
> have to be *persuasive*. "I want" doesn't cut it.
> 
> > You have not
> > stated any clearer opposition to that principle other than that
> > it is too much trouble.
> 
> Here are some reasons why what you want shouldn't happen:
> 
> * It will cost money (with no compensating advantage);
> * It will cost time (with no compensating advantage);
> * We're good with what we've got already - it works just fine.
> 
> Your reasons have to be better, stronger, more powerful, than those 
> reasons - and "it will cost money" is a very powerful reason indeed.

Cost-benefit studies are very difficult to do honestly. I doubt 
that the potential costs can be extimated with any accuracy and
I am sure the benfits are almost impossible to estimate. A single
sentence in the Standard might cause or prevent hundreds of calls 
to help desks or posts to usenet. And we would need to determine
how properly to discount the effort that will be spent in 2115
by forensic programmers trying to read legacy code.

I would argue that cost-benefit arguments should not be admitted
because there is no factual basis upon which to measure either.

As to the third point - I will answer with an anecdote. Once
upon a time I was evaluating nuclear weapon effects codes. I
hope I don't need to prove that nuclear effects code is an
important application. I observed that one of the programs was
using a subroutine to compute air pressures in shock waves and
the subroutine was giving answers that were, because of a faulty
unit conversion, about ten times larger than they should be. I
called the users of this code and pointed out the problem. They
thanked me said they were going to change nothing because "We're 
good with what we've got already - it works just fine."

To underline: complacency carries unknown risks.

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

#65738

From	Richard Heathfield <rjh@cpax.org.uk>
Date	2015-07-17 01:32 +0100
Message-ID	<mo9icv$hor$1@dont-email.me>
In reply to	#65730

On 17/07/15 01:05, David Kleinecke wrote:
> On Thursday, July 16, 2015 at 1:42:30 AM UTC-7, Richard Heathfield wrote:

<snip>

>> Here are some reasons why what you want shouldn't happen:
>>
>> * It will cost money (with no compensating advantage);
>> * It will cost time (with no compensating advantage);
>> * We're good with what we've got already - it works just fine.
>>
>> Your reasons have to be better, stronger, more powerful, than those
>> reasons - and "it will cost money" is a very powerful reason indeed.
>
> Cost-benefit studies are very difficult to do honestly.

Not this one. Cost > 0. Benefit currently == 0. It's a no-brainer. If 
you want to alter the equation, you have to show that your proposal 
results in a benefit. So far, you haven't done so.

> I doubt
> that the potential costs can be extimated with any accuracy and
> I am sure the benfits are almost impossible to estimate.

The cost will be significant. The benefit, as far as we can assess it at 
the moment, is 0. If you don't agree, you'll have to point out what the 
benefit is.

> A single
> sentence in the Standard might cause or prevent hundreds of calls
> to help desks or posts to usenet.

Can you provide an example of a relevant change to the Standard (i.e. 
one that requires hitherto unspecified behaviour to become 
implementation-defined) that will prevent hundreds of calls to helpdesks 
or posts to Usenet?

> And we would need to determine
> how properly to discount the effort that will be spent in 2115
> by forensic programmers trying to read legacy code.

I think you're entering into the realms of fantasy there. Let's start 
off by identifying a single solid benefit of your proposal. Just one, 
but do try to be convincing.

> I would argue that cost-benefit arguments should not be admitted
> because there is no factual basis upon which to measure either.

We know the cost will be greater than 0. We currently estimate the 
benefit to be 0.

> As to the third point - I will answer with an anecdote. Once
> upon a time I was evaluating nuclear weapon effects codes. I
> hope I don't need to prove that nuclear effects code is an
> important application. I observed that one of the programs was
> using a subroutine to compute air pressures in shock waves and
> the subroutine was giving answers that were, because of a faulty
> unit conversion, about ten times larger than they should be. I
> called the users of this code and pointed out the problem. They
> thanked me said they were going to change nothing because "We're
> good with what we've got already - it works just fine."

Perhaps they were right, and your observation was erroneous. We'll never 
know.

> To underline: complacency carries unknown risks.

Asking people to invest a lot of time and therefore money in a change 
that carries no compensating benefit carries the known risk that the 
request will be ignored.

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

#65745

From	James Kuyper <jameskuyper@verizon.net>
Date	2015-07-16 21:07 -0400
Message-ID	<mo9kdg$mlm$1@dont-email.me>
In reply to	#65730

On 07/16/2015 08:05 PM, David Kleinecke wrote:
> On Thursday, July 16, 2015 at 1:42:30 AM UTC-7, Richard Heathfield wrote:
>> On 16/07/15 05:19, David Kleinecke wrote:
...
>>> You have not
>>> stated any clearer opposition to that principle other than that
>>> it is too much trouble.
>>
>> Here are some reasons why what you want shouldn't happen:
>>
>> * It will cost money (with no compensating advantage);
>> * It will cost time (with no compensating advantage);
>> * We're good with what we've got already - it works just fine.
>>
>> Your reasons have to be better, stronger, more powerful, than those 
>> reasons - and "it will cost money" is a very powerful reason indeed.
>  
> Cost-benefit studies are very difficult to do honestly. I doubt 
> that the potential costs can be extimated with any accuracy and
> I am sure the benfits are almost impossible to estimate.

True - but we're not asking you to estimate the benefits, just describe
them. The costs of your proposal are substantial - I suspect that
they're significantly larger than you think they are. Therefore, the
benefits need to be substantial, too. The fundamental problem is that,
as far as we can see, the benefits are not merely minor, but practically
non-existent. The committee's decision to leave these things unspecified
suggests that a large group of intelligent experienced C expert
volunteers feels the same way. Your inability to articulate any benefits
from having these things documented is not helping your case.
-- 
James Kuyper

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

#65756 — We're good - don't you worry 'bout a thing, babe (Was: Unspecified behavior in C)

From	gazelle@shell.xmission.com (Kenny McCormack)
Date	2015-07-17 07:21 +0000
Subject	We're good - don't you worry 'bout a thing, babe (Was: Unspecified behavior in C)
Message-ID	<moaads$gpg$1@news.xmission.com>
In reply to	#65730

In article <64413a2c-f5fb-4bde-bfb6-166bb42143d7@googlegroups.com>,
David Kleinecke  <dkleinecke@gmail.com> wrote:
...
>As to the third point - I will answer with an anecdote. Once
>upon a time I was evaluating nuclear weapon effects codes. I
>hope I don't need to prove that nuclear effects code is an
>important application. I observed that one of the programs was
>using a subroutine to compute air pressures in shock waves and
>the subroutine was giving answers that were, because of a faulty
>unit conversion, about ten times larger than they should be. I
>called the users of this code and pointed out the problem. They
>thanked me said they were going to change nothing because "We're 
>good with what we've got already - it works just fine."
>
>To underline: complacency carries unknown risks.

Good story.  Well done!

Point: It is always hard to argue with a user who says "I'm fine.  Don't
worry..."

-- 
If you think you have any objections to anything I've said above, please
navigate to this URL:

    http://www.xmission.com/~gazelle/Truth

This should clear up any misconceptions you may have.

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

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

csiph-web

Unspecified behavior in C

Contents

#65593

#65600

#65601

#65650

#65659

#65700

#66023

#66039

#66239

#66258

#66412

#66270

#65679

#65681

#65684

#65688

#65730

#65738

#65745

#65756 — We're good - don't you worry 'bout a thing, babe (Was: Unspecified behavior in C)