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

#66825

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-08-03 17:46 -0700
Message-ID	<3e6d5525-35ec-4ee5-83ea-dc9c363b4564@googlegroups.com>
In reply to	#66795

On Monday, August 3, 2015 at 9:09:15 AM UTC-7, Ken Brody wrote:
> 
> But why *force* the compiler to use what you say is the "natural" order? 
> Perhaps it has just calculated c in the previous statement:
> 
>      c = some_function();
>      d = a + b + c;
 
Depends on how the compiler works. In my world the assembly language
version would be something like
    @ = some_function();   
    r1 = @;
    r2 = a
    r2 + b
    r2 + r1
    d = r2
That is, the function call doesn't store in c - it stores in some
scratch register I call @ which then must be saved. 

> Why force the compiler to ignore the fact that is already holds the value of 
> c in a register, and prevent it optimizing it to:
> 
>      d = (c + a) + b;
> 
    @ = some_function();   
    r1 = @;
    r1 + a
    r1 + b
    d = r1
but it is easy to see how an optimizer can get version 2 from version 1

> Or, let's take you "natural order" one step further:
> 
>      a + b + c + d ==>  ( ( a + b ) + c ) + d
> 
> Why not let a "hyperthreading" CPU do:
> 

>      ( a + b ) + ( c + d )
> 
> where (a+b) and (c+d) are calculated in parallel?
 
If you have a machine where that makes sense - go to it.

> Why encumber the compiler, preventing such optimizations?
 
I'm not preventing such optimizations - I'm just assigning them to the 
optimizer rather than the parser.

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

#66918

From	James Kuyper <jameskuyper@verizon.net>
Date	2015-08-05 12:34 -0400
Message-ID	<55C23B20.4040002@verizon.net>
In reply to	#66825

On 08/03/2015 08:46 PM, David Kleinecke wrote:
> On Monday, August 3, 2015 at 9:09:15 AM UTC-7, Ken Brody wrote:
>>
>> But why *force* the compiler to use what you say is the "natural" order? 
>> Perhaps it has just calculated c in the previous statement:
>>
>>      c = some_function();
>>      d = a + b + c;
>  
> Depends on how the compiler works. In my world the assembly language
> version would be something like
>     @ = some_function();   
>     r1 = @;
>     r2 = a
>     r2 + b
>     r2 + r1
>     d = r2
> That is, the function call doesn't store in c - it stores in some
> scratch register I call @ which then must be saved. 
> 
>> Why force the compiler to ignore the fact that is already holds the value of 
>> c in a register, and prevent it optimizing it to:
>>
>>      d = (c + a) + b;
>>
>     @ = some_function();   
>     r1 = @;
>     r1 + a
>     r1 + b
>     d = r1
> but it is easy to see how an optimizer can get version 2 from version 1
> 
>> Or, let's take you "natural order" one step further:
>>
>>      a + b + c + d ==>  ( ( a + b ) + c ) + d
>>
>> Why not let a "hyperthreading" CPU do:
>>
> 
>>      ( a + b ) + ( c + d )
>>
>> where (a+b) and (c+d) are calculated in parallel?
>  
> If you have a machine where that makes sense - go to it.
> 
>> Why encumber the compiler, preventing such optimizations?
>  
> I'm not preventing such optimizations - I'm just assigning them to the 
> optimizer rather than the parser.

You might not prevent such optimizations, but the C standard does not
permit them to be performed by conforming implementations of C. It does
so because, unlike the abstract operation of addition in conventional
math, addition of integer types in C can produce results that differ,
depending upon the which pairs of values added together.

Note that the C standard never even talks about a "parser" or an
"optimizer" - it merely talks about the grammar, and about permitted
optimizations, without specifying anything about which component of an
implementation is responsible for parsing the source code in accordance
with the grammar and performing optimizations. This permits, among other
things, implementations where different parts of each of those tasks are
performed by several different components.

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

#65567

From	Richard Heathfield <rjh@cpax.org.uk>
Date	2015-07-14 17:57 +0100
Message-ID	<mo3euu$8bf$1@dont-email.me>
In reply to	#65560

On 14/07/15 17:16, David Kleinecke wrote:

<snip>

> OK. I admit that it never occurred to me that anyone would object
> to better documentation as a goal.

Why is it "better"? You haven't explained this. "More" isn't necessarily 
"better". Although there are auto-documenting tools, they aren't 
particularly bright at anything very much more difficult than 
cataloguing. For the kind of documentation you are suggesting, *people* 
have to create the documents, and that means they will have to spend 
their time on it. And *that* means you have to provide some motivation 
for them so to do. Just saying "it would be better" isn't enough. You 
have to say /why/ it would be better.

> Actually my real goal is to make C programs more readable.

It is not clear how specifying behaviours that are currently 
/deliberately/ left unspecified (for good reasons that you have already 
been told about) would make C programs more readable. Would you care to 
elaborate?

> Metaphorically the language standard is the grammar of the language
> in which the program is written. So to reach my goal I want the
> grammar to be well understood.

Let's consider a grammar such as the one on p32 of my copy of the Dragon 
Book:

expr -> expr + term | expr - term | term
term -> term * factor | term / factor | factor
factor -> digit | ( expr )

This grammar is easy to understand. The order of evaluation is not 
specified. How would specifying it make the grammar easier to understand?

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

#65570

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-07-14 10:31 -0700
Message-ID	<67cfd75e-7c9e-43d3-96e3-07f8cca57b81@googlegroups.com>
In reply to	#65567

On Tuesday, July 14, 2015 at 9:57:37 AM UTC-7, Richard Heathfield wrote:
> On 14/07/15 17:16, David Kleinecke wrote:
> 
> <snip>
> 
> > OK. I admit that it never occurred to me that anyone would object
> > to better documentation as a goal.
> 
> Why is it "better"? You haven't explained this. "More" isn't necessarily 
> "better". Although there are auto-documenting tools, they aren't 
> particularly bright at anything very much more difficult than 
> cataloguing. For the kind of documentation you are suggesting, *people* 
> have to create the documents, and that means they will have to spend 
> their time on it. And *that* means you have to provide some motivation 
> for them so to do. Just saying "it would be better" isn't enough. You 
> have to say /why/ it would be better.
> 
> > Actually my real goal is to make C programs more readable.
> 
> It is not clear how specifying behaviours that are currently 
> /deliberately/ left unspecified (for good reasons that you have already 
> been told about) would make C programs more readable. Would you care to 
> elaborate?
> 
> > Metaphorically the language standard is the grammar of the language
> > in which the program is written. So to reach my goal I want the
> > grammar to be well understood.
> 
> Let's consider a grammar such as the one on p32 of my copy of the Dragon 
> Book:
> 
> expr -> expr + term | expr - term | term
> term -> term * factor | term / factor | factor
> factor -> digit | ( expr )
> 
> This grammar is easy to understand. The order of evaluation is not 
> specified. How would specifying it make the grammar easier to understand?
 
OK. When writing a compiler I don't follow the syntax of the
Standard. My syntax looks like this:

    expression = term Infix..
    term = (Prefix ...) primitive (Suffix ...)

Pardon my modified BNF 
    ( ..... ) means optional
    a ... means possibly repeated
    a b.. means possibly repeated like a b a b a ...

The Infixes are the binary operators; the Prefixs are the unary;
and Suffixs are also unary but follow rather than precede - there
are two normal Suffixe sin C - ++ and -- - I add others. 

There are considerable inner workings - each infix has two 
precedences and so on. But the order of evaluation is strictly
controlled (an optimization phase can change it). 

Your example in my notation is
    expr = term Additive..
    term = factor Multiplicative..
    factor = digit / embed
    embed = OPEN expr CLOSE
and the Multiplicatives have stronger precedence than the Additives.
The order is completely predicatable.

PS: In my system OPEN is a Prefix and CLOSE is a Suffix and there
is no recursion there. There is recursion in array primitives
    array BEGIN expression END
and function calls.

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

#65571

From	Richard Heathfield <rjh@cpax.org.uk>
Date	2015-07-14 18:50 +0100
Message-ID	<mo3i2m$kaq$1@dont-email.me>
In reply to	#65570

On 14/07/15 18:31, David Kleinecke wrote:
> On Tuesday, July 14, 2015 at 9:57:37 AM UTC-7, Richard Heathfield wrote:
>> On 14/07/15 17:16, David Kleinecke wrote:
>>
<snip>
>>
>> > Metaphorically the language standard is the grammar of the language
>> > in which the program is written. So to reach my goal I want the
>> > grammar to be well understood.
>>
>> Let's consider a grammar such as the one on p32 of my copy of the Dragon
>> Book:
>>
>> expr -> expr + term | expr - term | term
>> term -> term * factor | term / factor | factor
>> factor -> digit | ( expr )
>>
>> This grammar is easy to understand. The order of evaluation is not
>> specified. How would specifying it make the grammar easier to understand?
>
> OK. When writing a compiler I don't follow the syntax of the
> Standard.

But that's why we have standards - so that implementers who claim 
conformance to the Standard /do/ follow the syntax of the Standard!

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

#65678

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-07-15 20:59 -0700
Message-ID	<eee9aaaa-f9db-423d-b892-a4b827f0d23b@googlegroups.com>
In reply to	#65571

On Tuesday, July 14, 2015 at 10:50:50 AM UTC-7, Richard Heathfield wrote:
> On 14/07/15 18:31, David Kleinecke wrote:
> > On Tuesday, July 14, 2015 at 9:57:37 AM UTC-7, Richard Heathfield wrote:
> >> On 14/07/15 17:16, David Kleinecke wrote:
> >>
> <snip>
> >>
> >> > Metaphorically the language standard is the grammar of the language
> >> > in which the program is written. So to reach my goal I want the
> >> > grammar to be well understood.
> >>
> >> Let's consider a grammar such as the one on p32 of my copy of the Dragon
> >> Book:
> >>
> >> expr -> expr + term | expr - term | term
> >> term -> term * factor | term / factor | factor
> >> factor -> digit | ( expr )
> >>
> >> This grammar is easy to understand. The order of evaluation is not
> >> specified. How would specifying it make the grammar easier to understand?
> >
> > OK. When writing a compiler I don't follow the syntax of the
> > Standard.
> 
> But that's why we have standards - so that implementers who claim 
> conformance to the Standard /do/ follow the syntax of the Standard!
 
My version is one-to-one with the standard (except as below). It is
identical information-wise. One exception occurs when I must 
introduce more concepts. I can't allow 
    primitive = (OPEN expression CLOSE) / ...  
rather I must say 
    primitive = embedded-expression / ...
    embedded-expression = OPEN expression CLOSE
I might use the Standard's form but the subscript 'opt' makes it
imposssible (without much unnecessary flurry)

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

#65578

From	Keith Thompson <kst-u@mib.org>
Date	2015-07-14 11:34 -0700
Message-ID	<ln1tgalhap.fsf@kst-u.example.com>
In reply to	#65560

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> OK. I admit that it never occurred to me that anyone would object
> to better documentation as a goal.

Nobody objects to better documentation as a goal.

You appear to be assuming that *more* documentation is necessarily
*better* documentation.  It isn't.

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

#65920

From	raltbos@xs4all.nl (Richard Bos)
Date	2015-07-19 20:46 +0000
Message-ID	<55ac0bab.2772000@news.xs4all.nl>
In reply to	#65560

David Kleinecke <dkleinecke@gmail.com> wrote:

> OK. I admit that it never occurred to me that anyone would object
> to better documentation as a goal.

No, you're wrong _again_.

Nobody is objecting to _better_ documentation. What we're objecting to
is your unthinking (or at least not-willing-to-provide-thoughts-behind)
assumption that _more_ documentation is /ipso facto/ better.

And I'll go further than that: your assumption is simply wrong. The
extra documentation you ask for is going to harm your C programming
(mainly through leading you into further unwarranted assumptions),
rather than improve it.

Richard

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

#65442

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

David Kleinecke <dkleinecke@gmail.com> writes:
> On Saturday, July 11, 2015 at 5:15:58 PM UTC-7, Keith Thompson wrote:
[...]
>> You've answered none of the questions I asked.  Did you intend to?
>
> Most of your questions appear rhetorical to me. I don't answer
> rhetorical questions. 

None of those questions were rhetorical.  I do not understand your
position, and I'm trying to.  (Or rather, I was.)

>> The standard documents the language.  The documentation for a
>> particular implementation is likely to be useless without that
>> knowledge.
>> 
>> The C standard says that the order of evaluation of function
>> arguments is unspecified.  It also explains clearly what
>> "unspecified" means.  Apparently that's not good enough for you,
>> but you haven't explained why.
>  
> It doesn't explain what "unspecified" means other than undocumented
> implementation-defined.

A clearer explanation goes the other way.  Unspecified behavior is
behavior where the standard provides two or more possibilities.
Implementation-defined behavior is a subset of unspecified behavior,
where the implementation must document is choice.

I find that perfectly clear.

>                         I have suggested already that these should
> be documented just like all the other implemenation-defined features.
> And I have stated repeatedly that I want everything documented.  

Yes, you've stated it repeatedly -- and you've repeatedly failed to
explain why, even given questions about specific examples.

Given:
    f(g(), h())
the calls to g() and h() may occur in either order, and the
implementation is not required to document which order it chooses.
I don't know what benefit you think there would be in requiring all
conforming implementations to document their choice (which may be
made in a very complicated manner).

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

#65446

From	glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date	2015-07-12 19:53 +0000
Message-ID	<mnugkh$jp2$1@speranza.aioe.org>
In reply to	#65442

Keith Thompson <kst-u@mib.org> wrote:

(snip, someone wrote)
>>> The C standard says that the order of evaluation of function
>>> arguments is unspecified.  It also explains clearly what
>>> "unspecified" means.  Apparently that's not good enough for you,
>>> but you haven't explained why.

(snip) 
> A clearer explanation goes the other way.  Unspecified behavior is
> behavior where the standard provides two or more possibilities.
> Implementation-defined behavior is a subset of unspecified behavior,
> where the implementation must document is choice.

(snip)

> Given:
>    f(g(), h())
> the calls to g() and h() may occur in either order, and the
> implementation is not required to document which order it chooses.
> I don't know what benefit you think there would be in requiring all
> conforming implementations to document their choice (which may be
> made in a very complicated manner).

Yes, and we shouldn't programs that depend on the order.

It is still interesting to wonder...

Say we don't depend on the order, but allow that there might
be differences. 

Is it reasonably to expect, or to document one way or the other,
that one get the same order each time a program is run?
(That is, without recompiling, even though the standard likely
doesn't mention recompiling.)

Is it resonable to expect the same order recompiling the same
source with the same compiler on a different day?  I haven't
followed compiler technology so closely, but there have been
optimization methods that use random numbers, simulated annealing
being a popular one.  I believe it is used in logic optimization,
and should also be useful for compilers. That might result in
different code generated from the same source by the same
compiler.

Or, how about a statement inside a loop?  Even though the order
is unspecified, is it reasonable that it be the same executing
the same statement?

-- glen

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

#65448

From	James Kuyper <jameskuyper@verizon.net>
Date	2015-07-12 16:12 -0400
Message-ID	<55A2CA3B.3080405@verizon.net>
In reply to	#65446

On 07/12/2015 03:53 PM, glen herrmannsfeldt wrote:
> Keith Thompson <kst-u@mib.org> wrote:
...
>> Given:
>>    f(g(), h())
>> the calls to g() and h() may occur in either order, and the
>> implementation is not required to document which order it chooses.
>> I don't know what benefit you think there would be in requiring all
>> conforming implementations to document their choice (which may be
>> made in a very complicated manner).
> 
> Yes, and we shouldn't programs that depend on the order.
> 
> It is still interesting to wonder...

The fact that the order is not specified when you write f(g(),h()) gives
implementations the freedom to optimize the code by rearranging the
order. The fact that the order is not implementation-defined gives
implementations the freedom to use techniques for deciding the order
which are too complicated to explain in a document of reasonable length.

If the order actually matters, it's always possible to re-write the code
so that the desired order is mandatory:

   temp = g();
   f(temp, h());

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

#65046

From	James Kuyper <jameskuyper@verizon.net>
Date	2015-07-09 14:20 -0400
Message-ID	<mnmdvn$krp$1@dont-email.me>
In reply to	#65021

On 07/09/2015 12:15 PM, David Kleinecke wrote:
...
> 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. ...

I very much doubt that. I suspect that the writers of the C standard
made a decision in each case, while they were first writing it, which
terms to use - and frequently changed their minds during subsequent
discussions.

I can understand why someone who can't imagine why anything should be
left unspecified would think that it must have been done by mistake, but
I'm quite certain that the committee did it deliberately, for reasons
that made sense to them, and to me, if not to you.

...
> as I will say, I think a matter like whether "errno" is a macro is

The standard explicitly specifies that errno is a macro.

> already documented because what errno is is stated in the header
> <errno.h> ...

The text of errno.h (if it even exists - see below) is not considered
part of an implementation's documentation.

> ... which the user can read (in any sane development
> environment).

Standard headers need not be stored in header files, and the standard is
very carefully written to avoid mandating the existence of such files.
It always uses the term "header" to refer to the standard headers, and
"source file" to refer to user-provided files that are #included.  I
believe that there are real implementations which store only an internal
representation of each standard header in the compiler itself, rather
than storing them as separate text files. If there are separate text
files, they might be for documentation purposes only - if you had the
necessary permissions to modify them, it would have no affect on the
compilation of your programs, because it's only the purely internal
representations of the standard headers that matters.

The only things a user really needs to know about standard headers are
the things that can be found out by reading the C standard or by making
appropriate use of the macros #defined by those headers.
-- 
James Kuyper

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

#65054

From	Keith Thompson <kst-u@mib.org>
Date	2015-07-09 12:18 -0700
Message-ID	<lnvbdt87hc.fsf@kst-u.example.com>
In reply to	#65046

James Kuyper <jameskuyper@verizon.net> writes:
> On 07/09/2015 12:15 PM, David Kleinecke wrote:
[...]
>> as I will say, I think a matter like whether "errno" is a macro is
>
> The standard explicitly specifies that errno is a macro.

C11 does.

C90 and C99 are IMHO poorly worded.  N1256 (C99) 7.5p2 says:

    The macros are

        [SNIP]

    ; and

        errno

    which expands to a modifiable lvalue that has type int, the
    value of which is set to a positive error number by several
    library functions. It is unspecified whether errno is a macro
    or an identifier declared with external linkage.

So they say that errno is a macro, *and then* say it might not be.

C11 removed the permission for errno to be an identifier declared with
external linkage; it must be a macro.

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

#65136

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-07-10 09:47 -0700
Message-ID	<ee9cbc5b-7faf-48cb-9b5a-97f3cf9b9fcf@googlegroups.com>
In reply to	#65046

On Thursday, July 9, 2015 at 11:21:10 AM UTC-7, James Kuyper wrote:
> 
> Standard headers need not be stored in header files, and the standard is
> very carefully written to avoid mandating the existence of such files.
> It always uses the term "header" to refer to the standard headers, and
> "source file" to refer to user-provided files that are #included.  I
> believe that there are real implementations which store only an internal
> representation of each standard header in the compiler itself, rather
> than storing them as separate text files. If there are separate text
> files, they might be for documentation purposes only - if you had the
> necessary permissions to modify them, it would have no affect on the
> compilation of your programs, because it's only the purely internal
> representations of the standard headers that matters.
> 
> The only things a user really needs to know about standard headers are
> the things that can be found out by reading the C standard or by making
> appropriate use of the macros #defined by those headers.
 
I would assume that a standard header would include what the standard
says it includes. I have always wondered why the standard didn't just
present the header as a C header (perhaps in alternative versions) with
comments. Following your logic they didn't do that for good reasons. 
But I cannot imagine what those reasons might be (inability to agree
on an indenation strategy?)

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

#65147

From	James Kuyper <jameskuyper@verizon.net>
Date	2015-07-10 13:36 -0400
Message-ID	<55A00286.8070301@verizon.net>
In reply to	#65136

On 07/10/2015 12:47 PM, David Kleinecke wrote:
> On Thursday, July 9, 2015 at 11:21:10 AM UTC-7, James Kuyper wrote:
...
>> The only things a user really needs to know about standard headers are
>> the things that can be found out by reading the C standard or by making
>> appropriate use of the macros #defined by those headers.
>  
> I would assume that a standard header would include what the standard
> says it includes. ...

Bad assumption, and one that doesn't lead to any useful predictions. The
standard never says that any standard header includes any particular
code. All it says is what the effects of #including the header are:
mainly, that various types are defined, various functions with external
linkage are declared, and various macros are #defined. The standard says
nothing about how that is achieved, and it would be perfectly feasible
to store the information needed by the compiler to add the relevant
identifiers to various symbol tables, without ever creating any C text
that actually declares or #defines them.

> ... I have always wondered why the standard didn't just
> present the header as a C header (perhaps in alternative versions) with
> comments. Following your logic they didn't do that for good reasons. 
> But I cannot imagine what those reasons might be (inability to agree
> on an indenation strategy?) 

One key reason would be to protect the implementation from being messed
with by someone modifying the header files. Of course, the same effect
could be achieved by providing the header files for inspection by the
user, but using a different hidden source of same information when
actually compiling code.

Another reason is that people learn bad coding techniques by reading
standard headers. That's because correct coding techniques for parts of
the C standard library are different from the ones for user code. For
example, if a standard header defines any identifiers in addition to the
ones specified by the standard (and most do, for a variety of reasons),
they must be identifiers from the space of names reserved to the
implementation. A user-defined header file, on the other hand, is
prohibited from defining names from that name space. The purpose of
making it mandatory for the implementation, and prohibited for the user,
is to prevent clashes between implementation code and user code.

As a result, implementations often use names that start with either two
underscores, or one underscore and a capital letter for internal details
such as header guards. I have very frequently seen people who first
learned of header guards by reading standard header files, and
mistakenly thought that this naming convention was part of the "header
guard" concept, and so borrowed the same convention when creating
user-defined header guards. Such code has undefined behavior, precisely
because your user-defined header guard might conflict with the same
identifier being used for some other purpose by the implementation.

You have previously expressed opposition to both the concept and purpose
of the reserved name spaces, preferring that clashes between the C
standard library and user code be prevented by the same method that such
clashes are prevented with third party library code. In reality such
third party library identifier clashes are NOT prevented, but simply
dealt with after they are detected (and in some cases, the consequences
are too subtle to be easily detected). I don't approve of the idea that
the C standard library should use that same approach, and the committee
has made it very clear that they feel the same way.

Another reason is that any given standard header file may be meant to be
compiled by one and only one implementation of C. In that case, it might
be entirely reasonable for it to make heavy use of
implementation-specific features that are very strongly not recommended
in user code that is meant to be more portable. I imagine that this
might be what Richard Heathfield is referring to when he complains about
gcc's header files, saying that he can't speak gcc.

One prime example is the offsetof() macro. There's very simple, obvious
C construct for implementing it, which works correctly on many
platforms, but that code dereferences a null pointer, which has
undefined behavior. The implementor of the offsetof() macro knows for
certain what the actual behavior of that construct is, and will use it
only if that behavior is the desired behavior. However, user code that's
meant to be portable should never contain such constructs.

A final reason is to hide details from the users that the implementors
don't want them dealing with. For instance, any given standard library
function might be implemented as a macro that expands into code with
passes those same arguments to one or more other functions, possibly
with rearrangement of the order, changes in the values, or additional
arguments. As a general rule, the implementors would prefer that you not
call those other functions directly. You can't be tempted to do so if
there's no actual standard header file for you read that refers to that
function.

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

#65302

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-07-11 09:19 -0700
Message-ID	<c6a24009-ba0f-4240-b509-384c28849f3d@googlegroups.com>
In reply to	#65147

On Friday, July 10, 2015 at 10:36:19 AM UTC-7, James Kuyper wrote:
> On 07/10/2015 12:47 PM, David Kleinecke wrote:
> > On Thursday, July 9, 2015 at 11:21:10 AM UTC-7, James Kuyper wrote:
> ...
> >> The only things a user really needs to know about standard headers are
> >> the things that can be found out by reading the C standard or by making
> >> appropriate use of the macros #defined by those headers.
> >  
> > I would assume that a standard header would include what the standard
> > says it includes. ...
> 
> Bad assumption, and one that doesn't lead to any useful predictions. The
> standard never says that any standard header includes any particular
> code. All it says is what the effects of #including the header are:
> mainly, that various types are defined, various functions with external
> linkage are declared, and various macros are #defined. The standard says
> nothing about how that is achieved, and it would be perfectly feasible
> to store the information needed by the compiler to add the relevant
> identifiers to various symbol tables, without ever creating any C text
> that actually declares or #defines them.
> 
> > ... I have always wondered why the standard didn't just
> > present the header as a C header (perhaps in alternative versions) with
> > comments. Following your logic they didn't do that for good reasons. 
> > But I cannot imagine what those reasons might be (inability to agree
> > on an indenation strategy?) 
> 
> One key reason would be to protect the implementation from being messed
> with by someone modifying the header files. Of course, the same effect
> could be achieved by providing the header files for inspection by the
> user, but using a different hidden source of same information when
> actually compiling code.
> 
> Another reason is that people learn bad coding techniques by reading
> standard headers. That's because correct coding techniques for parts of
> the C standard library are different from the ones for user code. For
> example, if a standard header defines any identifiers in addition to the
> ones specified by the standard (and most do, for a variety of reasons),
> they must be identifiers from the space of names reserved to the
> implementation. A user-defined header file, on the other hand, is
> prohibited from defining names from that name space. The purpose of
> making it mandatory for the implementation, and prohibited for the user,
> is to prevent clashes between implementation code and user code.
> 
> As a result, implementations often use names that start with either two
> underscores, or one underscore and a capital letter for internal details
> such as header guards. I have very frequently seen people who first
> learned of header guards by reading standard header files, and
> mistakenly thought that this naming convention was part of the "header
> guard" concept, and so borrowed the same convention when creating
> user-defined header guards. Such code has undefined behavior, precisely
> because your user-defined header guard might conflict with the same
> identifier being used for some other purpose by the implementation.
> 
> You have previously expressed opposition to both the concept and purpose
> of the reserved name spaces, preferring that clashes between the C
> standard library and user code be prevented by the same method that such
> clashes are prevented with third party library code. In reality such
> third party library identifier clashes are NOT prevented, but simply
> dealt with after they are detected (and in some cases, the consequences
> are too subtle to be easily detected). I don't approve of the idea that
> the C standard library should use that same approach, and the committee
> has made it very clear that they feel the same way.
> 
> Another reason is that any given standard header file may be meant to be
> compiled by one and only one implementation of C. In that case, it might
> be entirely reasonable for it to make heavy use of
> implementation-specific features that are very strongly not recommended
> in user code that is meant to be more portable. I imagine that this
> might be what Richard Heathfield is referring to when he complains about
> gcc's header files, saying that he can't speak gcc.
> 
> One prime example is the offsetof() macro. There's very simple, obvious
> C construct for implementing it, which works correctly on many
> platforms, but that code dereferences a null pointer, which has
> undefined behavior. The implementor of the offsetof() macro knows for
> certain what the actual behavior of that construct is, and will use it
> only if that behavior is the desired behavior. However, user code that's
> meant to be portable should never contain such constructs.
> 
> A final reason is to hide details from the users that the implementors
> don't want them dealing with. For instance, any given standard library
> function might be implemented as a macro that expands into code with
> passes those same arguments to one or more other functions, possibly
> with rearrangement of the order, changes in the values, or additional
> arguments. As a general rule, the implementors would prefer that you not
> call those other functions directly. You can't be tempted to do so if
> there's no actual standard header file for you read that refers to that
> function.

And I, as a potential user, object to not being able to see how these
things are done. 

How can I, as a user be sure the implementation is not dropping
spyware into my code? So far, I think, the spies haven't gotten that
clever - but the potential exists. 

"Trust me" will not do. I imagine the only really satisfactory way to
operate would be to compile everything locally from source code I
have examined. Today that is just a dream. But there is no reason not
to advocate for better prodcedures.

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

#65310

From	James Kuyper <jameskuyper@verizon.net>
Date	2015-07-11 12:56 -0400
Message-ID	<55A14ABF.9060607@verizon.net>
In reply to	#65302

On 07/11/2015 12:19 PM, David Kleinecke wrote:
...
> And I, as a potential user, object to not being able to see how these
> things are done. 
> 
> How can I, as a user be sure the implementation is not dropping
> spyware into my code? So far, I think, the spies haven't gotten that
> clever - but the potential exists.

You can't, and seeing the header files won't help. If I were writing a
compiler to insert spyware into the compiled code, I certainly wouldn't
do it through the header files, I'd put the main part in the standard
library, and all of the identifiers with external linkage that are part
of the spyware would have names that sound reasonable. The compiler
would insert calls to the spyware into the compiled object modules.
There wouldn't be a single suspicious construct anywhere in any
human-readable file.

The only way to be sure a compiler isn't doing this is read and
correctly interpret every single byte of the generated machine code, and
understand exactly what it does, to make sure it doesn't do what you
don't want it to do. I don't have enough time to do that. I don't have
enough time to do even a tiny fraction of that amount of work. Do you?
If so, you're probably better off writing machine code directly - that
way you can be sure (modulo your own coding errors) that your program
does what you want it to do, and only what you want it to do.

If you have a lot of confidence in your ability to spot malicious code
constructs, I'd recommend looking at the winning entries and runners up
in the "Underhanded C Contest", <http://underhanded-c.org/>. It should
pretty thoroughly demolish your confidence. Note: the reason why it's
the "Underhanded C Contest" and not the "Underhanded Assembler Contest"
is that doing the same thing in assembler would be far too easy.

I'm not happy about the fact that I have no reasonable alternative to
trusting a lot of software written by other people - but that doesn't
change the fact that I do not, in fact, have any reasonable alternative.
The US government requires my company to give me IT security training
every year. I know what kinds of things they consider most important for
me to do to reduce our exposure to security threats. Examining the
header files of libraries I use is never even mentioned in those
training classes, and for good reason. If you exert reasonable care
about which software vendors you use (and exerting that care is the
system administrator's responsibility), there's literally hundreds of
other ways of spending your time to improve IT security that are a more
cost-effective use of your time than looking at the details of how the
standard library is implemented.

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

#65388

From	gordonb.j19di@burditt.org (Gordon Burditt)
Date	2015-07-11 20:36 -0500
Message-ID	<mvednWN3TMAAWTzInZ2dnUU7-UWdnZ2d@posted.internetamerica>
In reply to	#65302

> How can I, as a user be sure the implementation is not dropping
> spyware into my code? So far, I think, the spies haven't gotten that
> clever - but the potential exists. 

They are a lot more clever than you think.

There has already been a demonstration of this on UNIX, putting a
backdoor in the 'login' program, and some modifications to the C
compiler.  All of this was done with *NO SOURCE CODE CHANGES*.  A
hacked compiler (binary) recognized certain sections of code and
effectively modified them during compilation.

> "Trust me" will not do. I imagine the only really satisfactory way to
> operate would be to compile everything locally from source code I
> have examined. 

This is insufficient, unless you start with source code and no
binaries whatever *MANUALLY* compile it all (e.g. with pencil and
paper, or perhaps a small magnet and a floppy disk and no floppy
drive).  While you're at it, consider hacks in the microcode of the
processor you are using, perhaps inserted by a nation not friendly
to the USA.  The US military does worry about this.

> Today that is just a dream. 

Compiling FreeBSD (or Linux, or various other open-source distributions)
from source code is not a dream, but you need binaries to bootstrap
it, and that's where the problem starts.  Examining all the code
in FreeBSD, particularly the C compiler and libraries, sufficiently
to detect hacks probably is a dream.

> But there is no reason not
> to advocate for better prodcedures.

If you recompiled the entire system with the hacked compiler and
unmodified source code, you got the hacked compiler and the version
of login with the backdoor.  If you recompiled the entire system
with an unhacked compiler and unmodified source code, you got the
unhacked compiler and a version of login without the backdoor.


This hack is described by the author in "Reflections on Trusting
Trust", by Ken Thompson, Communications of the ACM, Volume 27, No.
8, August 1984.

I think this is an accurate copy:

http://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html


I do recall accidentally doing something not quite so sneaky as
this with a Z80 assembler.  The original z80 assembler had this big
table of opcodes.  A newer version added the feature that an opcode
could be used as a symbol with the opcode value being the value of
the symbol.  Later, the whole opcode table was changed to use the
value of the symbol in the opcode table.

It was discovered that the opcode generated for one of the more
obscure instructions was wrong.  Then it was discovered that the
erroneous opcode was nowhere in the source code to fix; the value
had been inherited from generations of this z80 assembler, each
version being used to create the next.  The erroneous opcode value
passed from each version to the next.

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

#65424

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-07-12 10:10 -0700
Message-ID	<3d30d407-5621-4158-83b9-274c8ca04b5e@googlegroups.com>
In reply to	#65388

On Saturday, July 11, 2015 at 6:36:38 PM UTC-7, Gordon Burditt wrote:
> > How can I, as a user be sure the implementation is not dropping
> > spyware into my code? So far, I think, the spies haven't gotten that
> > clever - but the potential exists. 
> 
> They are a lot more clever than you think.
> 
> There has already been a demonstration of this on UNIX, putting a
> backdoor in the 'login' program, and some modifications to the C
> compiler.  All of this was done with *NO SOURCE CODE CHANGES*.  A
> hacked compiler (binary) recognized certain sections of code and
> effectively modified them during compilation.
> 
> > "Trust me" will not do. I imagine the only really satisfactory way to
> > operate would be to compile everything locally from source code I
> > have examined. 
> 
> This is insufficient, unless you start with source code and no
> binaries whatever *MANUALLY* compile it all (e.g. with pencil and
> paper, or perhaps a small magnet and a floppy disk and no floppy
> drive).  While you're at it, consider hacks in the microcode of the
> processor you are using, perhaps inserted by a nation not friendly
> to the USA.  The US military does worry about this.
> 
> > Today that is just a dream. 
> 
> Compiling FreeBSD (or Linux, or various other open-source distributions)
> from source code is not a dream, but you need binaries to bootstrap
> it, and that's where the problem starts.  Examining all the code
> in FreeBSD, particularly the C compiler and libraries, sufficiently
> to detect hacks probably is a dream.
> 
> > But there is no reason not
> > to advocate for better prodcedures.
> 
> If you recompiled the entire system with the hacked compiler and
> unmodified source code, you got the hacked compiler and the version
> of login with the backdoor.  If you recompiled the entire system
> with an unhacked compiler and unmodified source code, you got the
> unhacked compiler and a version of login without the backdoor.
> 
> 
> This hack is described by the author in "Reflections on Trusting
> Trust", by Ken Thompson, Communications of the ACM, Volume 27, No.
> 8, August 1984.
> 
> I think this is an accurate copy:
> 
> http://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html
> 
> 
> I do recall accidentally doing something not quite so sneaky as
> this with a Z80 assembler.  The original z80 assembler had this big
> table of opcodes.  A newer version added the feature that an opcode
> could be used as a symbol with the opcode value being the value of
> the symbol.  Later, the whole opcode table was changed to use the
> value of the symbol in the opcode table.
> 
> It was discovered that the opcode generated for one of the more
> obscure instructions was wrong.  Then it was discovered that the
> erroneous opcode was nowhere in the source code to fix; the value
> had been inherited from generations of this z80 assembler, each
> version being used to create the next.  The erroneous opcode value
> passed from each version to the next.

In the end all coding is assembly. It might be a good idea to 
distribute code not as binaries but as assembly language. Save me
the trouble of dissambling at the cost of assembling at installation
time. 

My experience with assemblers is that assembly code can be written
in such a way as to be uncomprehensible but that compiler-written
code is usually easy enough to follow. I would simply reject any
binary that I could not read. I know most people will never bring
themselves to read the code - high-order or assembly - but I think
it should be possible for the specialist.

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

#65053

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2015-07-09 20:13 +0100
Message-ID	<87io9tywig.fsf@bsb.me.uk>
In reply to	#65021

David Kleinecke <dkleinecke@gmail.com> writes:
<snip>
> There are other signs of haste in the
> standard (eg "sizeof" as an operator).

It was there as a operator with that spelling since before K&R wrote the
first C book.  By the late 1980s, it would have been be daft to change
it with so much existing code around (quite apart from there being
nothing much wrong with it).

<snip>
-- 
Ben.

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

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

csiph-web

Unspecified behavior in C

Contents

#66825

#66918

#65567

#65570

#65571

#65678

#65578

#65920

#65442

#65446

#65448

#65046

#65054

#65136

#65147

#65302

#65310

#65388

#65424

#65053