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

Groups > comp.lang.forth > #38202 > unrolled thread

rhel 7 and kforth

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

Contents

  rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-15 11:20 -0700
    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-15 19:09 -0700
    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 04:13 -0700
      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 04:55 -0700
        Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-16 12:08 +0000
          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 05:29 -0700
            Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 07:07 -0700
              Re: rhel 7 and kforth franck.bensusan@gmail.com - 2015-04-16 07:44 -0700
                Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 08:14 -0700
            Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-16 14:02 +0000
              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 08:12 -0700
        Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 12:25 -0700
          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 17:02 -0700
            Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 17:06 -0700
              Re: rhel 7 and kforth foxaudioresearch@gmail.com - 2015-04-16 17:24 -0700
                Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 17:39 -0700
                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-16 17:47 -0700
                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 18:44 -0700
                    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 18:50 -0700
                      Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-16 19:10 -0700
                        Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 19:29 -0700
                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 20:10 -0700
                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-16 20:27 -0700
                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 02:04 -0700
                                Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-17 11:41 +0000
                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 14:45 -0700
                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:01 +0000
                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 07:47 -0700
                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 08:35 -0700
                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 10:33 -0700
                                      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 11:15 -0700
                                        Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 11:47 -0700
                                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 14:51 -0700
                                          Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:41 +0000
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 11:42 -0700
                                              Re: rhel 7 and kforth "Elizabeth D. Rather" <erather@forth.com> - 2015-04-24 09:02 -1000
                                              Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 10:53 +0000
                                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-05-03 17:22 -0700
                                                  Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 10:23 +0000
                                          Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-22 00:10 +0200
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-21 17:45 -0700
                                            Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 13:08 +0000
                                  Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 20:27 +0000
                                    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 14:41 -0700
                                      Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:11 +0000
                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 15:47 -0700
                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:34 +0000
                                      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-18 14:09 -0700
                                        Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-19 20:31 -0700
                                          Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 11:35 +0000
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-21 18:07 -0700
                                              Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 11:21 +0000
                                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 19:34 -0700
                                                  Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 08:36 +0000
                                                    Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-25 11:36 +0000
                                                      Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 16:29 +0000
                              Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-19 10:08 +0000
                                Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-19 20:11 -0700
                                Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 12:05 +0000
                                  Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-22 01:27 +0200
                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-21 18:18 -0700
                                      Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 11:00 +0000
                                        Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 11:28 -0700
                                          Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-25 01:34 +0200
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 21:07 -0700
                                            Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 16:41 +0000
                                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-25 10:06 -0700
                                                Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-26 14:56 +0000
                                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-26 20:22 -0700
                                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 09:02 +0000
                                                      Re: rhel 7 and kforth mhx@iae.nl - 2015-04-27 03:59 -0700
                                                      Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-27 15:45 +0000
                                                      Re: rhel 7 and kforth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-27 18:09 -0400
                                                      Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 03:55 +0200
                                                      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-27 19:30 -0700
                                                        Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-27 19:44 -0700
                                                        Re: rhel 7 and kforth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-28 02:03 -0400
                                                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 01:44 -0700
                                                            Re: rhel 7 and kforth Mark Wills <markwills1970@gmail.com> - 2015-04-28 02:44 -0700
                                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-28 16:47 -0700
                                                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 17:00 -0700
                                                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-28 17:14 -0700
                                                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 17:59 -0700
                                                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-28 21:41 -0700
                                                                  Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-29 03:07 +0200
                                                                    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 18:13 -0700
                                                              Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-29 00:07 +0000
                                                        Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 22:22 +0200
                                                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 14:23 -0700
                                                            Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 23:51 +0200
                                                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 16:50 -0700
                                                            Re: rhel 7 and kforth David Thompson <dave.thompson2@verizon.net> - 2015-05-10 12:24 -0400
                                                  Re: rhel 7 and kforth mhx@iae.nl - 2015-04-26 22:16 -0700
                                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 09:19 +0000
                                                      Re: rhel 7 and kforth mhx@iae.nl - 2015-04-27 04:03 -0700
                                                      Re: rhel 7 and kforth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-27 18:21 -0400
                                          Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-01 14:46 +0000
                                      Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-23 16:46 +0200
                          Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 10:35 +0000
                            Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 08:43 -0700
    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 08:41 -0700

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

#38470

Bernd Paysan <bernd.paysan@gmx.de> writes:
> 1 cells sp @ + @ -1 sp +! sp @ !
> Funny enough, that is *exactly* what K&R's compiler did, including 
> converting it to postfix threaded code.

K&R never wrote a compiler AFAIK.  Ritchie wrote a compiler in the
pre-ANSI C era, whose dialect had similarities and differences with ANSI
C, roughly like FIG Forth vs. ANS Forth.  K&R wrote a book about C that
was widely used as a reference manual, though Harbison & Steele's "C: A
Reference Manual" was much more solid.  I have the 2nd edition (1988) of
K&R's book.  Increment and decrement expressions are on page 43 and it
says nothing about this issue.  If it says it somewhere else I'd
appreciate a page number.

> That's an expression with a well-defined semantics in K&R C,

Where is it defined?  If you mean it was observable but undocumented
behavior in some particular implementation, that's not what I'd call
"well-defined".

> IMHO the most obvious misconception of the C developers is that
> "undefined = fast".  That's not the point.  When you write a program,
> you want to express your algorithms, so it has to be well-defined.

That is a reasonable thing for developers to want, and for language
designers to specify.  However, the designers of C didn't go that
route.  Maybe you want Ada.

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

#38496

Bernd Paysan <bernd.paysan@gmx.de> writes:
>E.g. if I do a + in Forth on a two's complement system, it will wrap around, 
>because + is defined for both signed and unsigned numbers, and what's an 
>overflow for a signed number is a normal operation for the unsigned number 
>and vice versa.

Forth-94 does not define integer overflow, neither for signed nor for
unsigned numbers, and Forth-2012 has not improved that.  But as you
point out, it is hard to imagine a system where + does not wrap
around, because the same + works for both signed and unsigned numbers.
In particular, on 1s-complement and sign-magnitude systems you have
different addition operations for signed and unsigned addition.

I asked that question many years ago, and from the answer from a TC
member puzzled the following together: The way Forth-94 (2012) would
be implemented on a 1s-complement or sign-magnitude system would be to
have the signed addition as +, and the unsigned numbers as a subset of
the signed numbers (e.g., 17-bit signed numbers and 16-bit unsigned
numbers).

One could even test how viable that approach is on a 2s-complement
system, by implementing + as signed overflow-trapping operation.

Anyway, 2s-complement with wraparound is common practice, so we should
standardize it.

>IMHO the most obvious misconception of the C developers is that "undefined = 
>fast".  That's not the point.  When you write a program, you want to express 
>your algorithms, so it has to be well-defined.

I think it's a misconception of the miscompiler maintainers, not of C
developers (some developers may also suffer from this misconception as
a result from advocacy from miscompiler defenders).  And the problem
is that the only programs they care about are those that are not being
developed, but were developed once upon a time and are now cast in
stone: benchmarks.  So unlike production programs, where you solve a
performance problem by changing the source code, the only way to
improve performance for these programs is compiler heroics; and the
compiler can be the more heroic, the less complete the specification
is it has to satisfy.  So what we get is that they use the C standard
as the only specification, plus adding those features that the SPEC
benchmarks use (but only in a very limited way, and of course
undocumented).

>  If you don't check array 
>bounds to gain speed, your compiler still can be well-defined: a[100] of an 
>int a[something]; array is accessing the memory location 100 ints further 
>from the start of a, no matter how big that "something" really is.  That's 
>defined behavior, undefined is only what kind of data there is at a[100], 
>because if something<100, it's certainly not part of the array a[], and the 
>memory layout of the rest of the system isn't easy to predict.
>
>A standard body of course simply writes "it's undefined", because vendor IBM 
>AS/400 actually does implement array boundary checking even for C.

Even without array bounds checking, you can get a SIGSEGV, and on a
machine with array bounds checking, you get an exception, not an
endless loop.

A standards body writes "undefined behaviour" or "ambiguous condition"
because there is no common practice concerning the results, and they
therefore don't want to specify it any further.  Taking that as excuse
for arbitrary miscompilation is the fault of the compiler maintainers
and their fault alone.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#38296

In article <87a8y695hs.fsf@jester.gateway.pace.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
<SNIP>
>
>It's not a compiler problem, it's a problem with C itself, which in turn
>stems from the optimization-crazed C culture that doesn't consider it to
>be a problem.

I think it is a problem in programming full stop.
What is the value of an expression f()+g() in the circumstance of
side effects (i/o changing global variables etc.) ?
In forth if we say  f g + , we know that f is executed first
then g . In many languages operands are defined to be concurrent,
meaning that f and g could be executed even in parallel processes or
threads.

If we want to take advantage of multi-cores, I'm afraid we will have to
pay attention to this, and not expect sloppy code to stay working
because it always worked.

Algol 68 makes you very aware of this, it is full of
explicit mention like, "if you pass values to a function, make sure
that it works if those values are calculated in parallel."
(At a time parallel processing was far off, it is just mathematical
thinking.)

It is the same as in real time programming. "The chance that that
flag is up is minimal because the the interrupt routine is so fast..."

<SNIP>

>That's one approach, but I think it's more accurate to say it's relying
>less on your knowledge of the C language.

I'd say more knowledge of C, less trusting tradition.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#38301

On Friday, April 17, 2015 at 3:27:44 PM UTC-5, Albert van der Horst wrote:
...
> I'd say more knowledge of C, less trusting tradition.
> 

It's easier for me if I think of ISO C as a new language, instead of an incrementally modified language from the 1990s. But, I think they risk making the language so full of hazards that only a machine will be able to program in C without writing a simple hello world type program without using undefined expressions.

I wonder if the approach to parallel programming isn't upside down. Instead of the compiler/programmer breaking the computation into parallel pieces to run on distributed nodes, maybe simple sequential algorithms on distributed nodes could be combined to observe the result, which is the answer to some computation problem. If the result of combining simple distributed tasks with computation problems of interest can be linked, then there is no need for fancy compilers with lots of restrictions. Of course, nothing guarantees such a mapping can be found, in general.

Krishna

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

#38340

krishna.myneni@ccreweb.org writes:
>On Friday, April 17, 2015 at 3:27:44 PM UTC-5, Albert van der Horst wrote:
>...
>> I'd say more knowledge of C, less trusting tradition.
>>=20
>
>It's easier for me if I think of ISO C as a new language, instead of an inc=
>rementally modified language from the 1990s. But, I think they risk making =
>the language so full of hazards that only a machine will be able to program=
> in C without writing a simple hello world type program without using undef=
>ined expressions.

This lack of standardization already existed in the first ISO C from
1990 (which is the same as ANSI C from 1989).  The current crop of
compiler maintainers like to blame the standard for their own
misdeeds, but it's their decision to compile programs differently than
their compilers did earlier, the standard did not force them.

And yes, you are right, when interpreted the way these C compiler
maintainers do, C is a language full of hazards, and there are hardly
any programs written in C; "Hello, world", and not much else.

>I wonder if the approach to parallel programming isn't upside down.

It's not a real approach to parallel programming, i.e., nobody writes
f()+g() with the expectation that the compiler will produce two
threads for the two calls.  It is, however, what some compilers try in
order to beat other compilers in the SPEC CPU game (and it seems that
this is the only thing that counts for the compiler maintainers).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#38306

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
> What is the value of an expression f()+g() in the circumstance of
> side effects (i/o changing global variables etc.) ?

Indeed, in Haskell such an expression isn't even legal and would be
rejected by the compiler.  The only way to run two separate
side-effecting actions in the same thread is to connect them through an
explicit sequencing operator.

> In many languages operands are defined to be concurrent, meaning that
> f and g could be executed even in parallel processes or threads.

Haskell is like that in principle, but if you say f+g then f and g are
required to have no side effects.  The only values that can have side
effects in Haskell have a special type signature and you can't just add
them like that.

> (At a time parallel processing was far off, it is just mathematical
> thinking.)

I think there was a similar situation in functional programming, except
the goal was to just not have side effects, since among other things
that lets certain verification techniques work.

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

#38342

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <87a8y695hs.fsf@jester.gateway.pace.com>,
>Paul Rubin  <no.email@nospam.invalid> wrote:
><SNIP>
>>
>>It's not a compiler problem, it's a problem with C itself, which in turn
>>stems from the optimization-crazed C culture that doesn't consider it to
>>be a problem.

That's not the C culture, that's a mental condition affecting C
compiler maintainers; maybe it comes from using C++.

>I think it is a problem in programming full stop.
>What is the value of an expression f()+g() in the circumstance of
>side effects (i/o changing global variables etc.) ?
>In forth if we say  f g + , we know that f is executed first
>then g . In many languages operands are defined to be concurrent,
>meaning that f and g could be executed even in parallel processes or
>threads.
>
>If we want to take advantage of multi-cores, I'm afraid we will have to
>pay attention to this, and not expect sloppy code to stay working
>because it always worked.

No, if we want to take advantage of multi-cores, we need to write
programs for multi-cores, not break working programs and do some
mudslinging (such as "sloppy code") in order to shift the blame to the
victim.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#38361

On Saturday, April 18, 2015 at 9:41:10 AM UTC-5, Anton Ertl wrote:
> albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
...
> >If we want to take advantage of multi-cores, I'm afraid we will have to
> >pay attention to this, and not expect sloppy code to stay working
> >because it always worked.
> 
> No, if we want to take advantage of multi-cores, we need to write
> programs for multi-cores, not break working programs and do some
> mudslinging (such as "sloppy code") in order to shift the blame to the
> victim.
> ...

This article shows some scary examples of what C compilers can do, which I don't think can be blamed on "sloppy code".

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html

Krishna

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

#38401

krishna.myneni@ccreweb.org writes:
> This article shows some scary examples of what C compilers can do,
> which I don't think can be blamed on "sloppy code".
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html

Well, it depends on what you mean by sloppy.  Some of the examples were
carefully written, yet buggy due to incorrect assumptions about C
semantics.  So they were non-sloppy at one level, but arguably sloppy at
another.  It appears difficult or impossible to write large C programs
that are free of such errors, at least with typical industry coding and
review/QA processes.  But, I think we're no longer in an era where it's
worth writing large C programs.  Smaller ones are possibly easier to
validate.

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

#38411

Paul Rubin <no.email@nospam.invalid> writes:
>krishna.myneni@ccreweb.org writes:
>> This article shows some scary examples of what C compilers can do,
>> which I don't think can be blamed on "sloppy code".
>> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
>
>Well, it depends on what you mean by sloppy.  Some of the examples were
>carefully written, yet buggy due to incorrect assumptions about C
>semantics.  So they were non-sloppy at one level, but arguably sloppy at
>another.  It appears difficult or impossible to write large C programs
>that are free of such errors, at least with typical industry coding and
>review/QA processes.

So if you use typical industry coding and review/QA processes, the
result is "sloppy code"?  Actually, even if you are more diligent than
typical in the industry, you can still produce programs that contain
"undefined behaviour" according to the C standard.  Somehow that is
not really compatible with the meaning of "sloppy" accoring to the
dictionary.

>But, I think we're no longer in an era where it's
>worth writing large C programs.  Smaller ones are possibly easier to
>validate.

My experince is that it is very easy to write C programs (or program
fragments) of any size (ok, maybe not with <3 tokens, but I guess you
had a different definition of "large" in mind) that contain "undefined
behaviour", and you won't find a number of them with the usual QA
process of testing.  My impression is that program size contributes
only inasfar as that there are more places where "undefined behaviour"
can occur, but does not make the problem worse in other ways.

Anyway, you are right that it is difficult or impossible to write
(large) C programs that do not contain "undefined behaviour".  Which
leads to the question what the motives of those people are who claim
that its fine if compilers miscompile programs with "undefined
behaviour" (the concrete phrases that these people use escape me at
the moment).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#38471

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> So if you use typical industry coding and review/QA processes, the
> result is "sloppy code"?

Sloppiness is relative of course, but yeah, an awful lot of industry
code I've had contact with could truthfully be called sloppy.

> My impression is that program size contributes [to UB] only inasfar as
> that there are more places where "undefined behaviour" can occur, but
> does not make the problem worse in other ways.

It's like the issue with malloc/free that you describe in your GC paper.
Once the program is big enough, lots of the code behavior is going to
depend on long chains of inferences from multiple faraway parts of the
program that get too complicated for humans to keep track of.  Anyone
working on the program will have to concentrate on localized regions
without complete understanding of what the rest of the program is doing.
There are reasonable techniques for maintaining modularity in this
situation but you know what happens when there are memory constraints,
schedule pressure in the project, etc.  Another thing that happens with
C programs (especially with embedded code) is it gets written by
electrical engineers who are very smart people but who don't know
anything about software, and made spaghetti up to the limit of their
ability to make it work.  So you get something that took huge brainpower
even from the original author who understood everything, and is
incomprehensible by the time a few dozen other people have messed with
it, adding and changing stuff without understanding it so well.

With a small program the author/maintainer can really understand and
double-check everything, you can have a code review where multiple
programmers examine it in detail and really check everything, etc.  So
you have much better chances that way.

> Anyway, you are right that it is difficult or impossible to write
> (large) C programs that do not contain "undefined behaviour".  Which
> leads to the question what the motives of those people are who claim
> that its fine if compilers miscompile programs with "undefined
> behaviour"

Consider that one of the commonest forms of UB is out-of-bounds array
references / buffer overruns.  Would you say those are "miscompiled"?
Why do you keep saying "miscompiled" if the compiler does what the
specification says?  Regehr has similar concerns but at least he's
willing to propose a new specification saying what he wants the compiler
to do instead.  You seem to just want the compiler writers to run your
program through a clairvoyance module to guess your intentions in it.

Me, I think C is hopeless, it inherently has UB, and there's just a
question of having larger or smaller amounts of it.  But even the most
defensible kinds like array overruns cause immense amounts of real-world
bugs.  It makes more sense to define a language that's completely free
of UB if implemented strictly according to the spec (e.g. that means all
subscripts have to be checked).  Then implementations can introduce
pragmas that turn off some of the checks, and the programmer can use
these in critical loops when maximum speed is needed, at the expense of
potentially creating UB, but only in (hopefully) very controlled
situations.

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

#38494

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> So if you use typical industry coding and review/QA processes, the
>> result is "sloppy code"?
>
>Sloppiness is relative of course, but yeah, an awful lot of industry
>code I've had contact with could truthfully be called sloppy.

Sure, but that's not the issue here.  As I wrote: Actually, even if
you are more diligent than typical in the industry, you can still
produce programs that contain "undefined behaviour" according to the C
standard.

>> My impression is that program size contributes [to UB] only inasfar as
>> that there are more places where "undefined behaviour" can occur, but
>> does not make the problem worse in other ways.
>
>It's like the issue with malloc/free that you describe in your GC paper.

I don't think it's like that at all.

>Once the program is big enough, lots of the code behavior is going to
>depend on long chains of inferences from multiple faraway parts of the
>program that get too complicated for humans to keep track of.  Anyone
>working on the program will have to concentrate on localized regions
>without complete understanding of what the rest of the program is doing.

For now the undefined behaviour problems I have seen seemed to be
relatively local.  Certainly the miscompilations were, because
compilers are usually worse than programmers at finding out something
that's combined from faraway parts of the programs; and when a
compiler does not find out that the behaviour is undefined, it tends
to compile what the programmer expects (and vice versa: the programmer
expects what the compiler normally compiles).

>There are reasonable techniques for maintaining modularity in this
>situation but you know what happens when there are memory constraints,
>schedule pressure in the project, etc.  Another thing that happens with
>C programs (especially with embedded code) is it gets written by
>electrical engineers who are very smart people but who don't know
>anything about software, and made spaghetti up to the limit of their
>ability to make it work.  So you get something that took huge brainpower
>even from the original author who understood everything, and is
>incomprehensible by the time a few dozen other people have messed with
>it, adding and changing stuff without understanding it so well.
>
>With a small program the author/maintainer can really understand and
>double-check everything, you can have a code review where multiple
>programmers examine it in detail and really check everything, etc.  So
>you have much better chances that way.

Sure, but that has nothing to do with undefined behaviour.

>> Anyway, you are right that it is difficult or impossible to write
>> (large) C programs that do not contain "undefined behaviour".  Which
>> leads to the question what the motives of those people are who claim
>> that its fine if compilers miscompile programs with "undefined
>> behaviour"
>
>Consider that one of the commonest forms of UB is out-of-bounds array
>references / buffer overruns.  Would you say those are "miscompiled"?

When gcc turns a bounded loop that contains a out-of-bounds array read
into an endless loop, then yes, that is miscompiled.  Because that
happened in a SPEC benchmark, the gcc maintainers partly fixed this
miscompilation before releasing the compiler, but from what I hear it
still occurs in cases that are slightly different from the case in the
benchmark.

If, OTOH, a compiler compiles an out-of-bounds array access when the
programmer writes an out-of-bounds array access, then the compiler is
doing what programmer expects; ok, there were people who suspect a
compiler bug when a program with an out-of-bounds access exhibits
unexpected behaviour because, e.g., another variable was overwritten,
but once the out-of-bounds access is pointed out to them, they do not
think that it is miscompilation.

As for being one of the commonest forms, do you have numbers for that?
I would expect it to be relatively rare, because it usually is a bug
even when compiled correctly.

>Why do you keep saying "miscompiled" if the compiler does what the
>specification says?

The C standard does not say anything about what the compiler should do
in case of undefined behaviour, so the compiler does not do "what the
specification says".

The specification in case of the C standard is incomplete, as is
evidenced by the fact that nearly all C programs exhibit undefined
behaviour (or, in the words of the miscompiler defenders, are "not C
programs"), including the miscompilers themselves.

Treating the C standard as a complete specification may be an
interesting academic exercise, but is not the right attitude for a
production compiler.  Of course, the gcc maintainers know that, too,
and compile at least the SPEC benchmarks as intended (despite
exhibiting undefined behaviour), but they put up the "what the
specification says" excuse all the time.

It sure is convenient to have a specification that excludes all
serious programs; you never really have to fix a bug; if there's a bug
report you don't like, you just point out that the code exhibits
undefined behaviour and mark it as invalid.

>Regehr has similar concerns but at least he's
>willing to propose a new specification saying what he wants the compiler
>to do instead.  You seem to just want the compiler writers to run your
>program through a clairvoyance module to guess your intentions in it.

You don't need to repeat the refuted straw men of Andrew Haley.  I
already told him that a reasonably conservative attitude would be
sufficient, as is evidenced by the versions of gcc up to 2.7: produced
efficient code and no miscompilation (well, a compiler bug now and
then, but not intentional miscompilation as with todays gccs).

The proposed features of Regehr's friendly C sound reasonable.

>Me, I think C is hopeless

Yes, that seems to be a common attitude of miscompiler defenders.
Maybe you like miscompilation so much because you wish for C to
vanish.

>But even the most
>defensible kinds like array overruns cause immense amounts of real-world
>bugs.  It makes more sense to define a language that's completely free
>of UB if implemented strictly according to the spec (e.g. that means all
>subscripts have to be checked).  Then implementations can introduce
>pragmas that turn off some of the checks, and the programmer can use
>these in critical loops when maximum speed is needed, at the expense of
>potentially creating UB, but only in (hopefully) very controlled
>situations.

You mean, a language like C#?  A student of mine once implemented a
Postscript interpreter in C#
<http://www.complang.tuwien.ac.at/Diplomarbeiten/baumann10.pdf>.  One
might think that, given the high-level data model of Postscript, this
may be relatively straightforward to implement efficiently, but that
turned out not to be the case.  The student had to implement basic
data structures of Postscript in relatively inefficient ways.

There is a need for low-level languages like C and Forth.

BTW, why are array overruns more defensible than, say, left-shifting
negative numbers?  Or other undefined behaviours?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#38589

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>an awful lot of industry code... could truthfully be called sloppy.
> Sure, but that's not the issue here.  As I wrote: Actually, even if
> you are more diligent than typical in the industry, you can still
> produce programs that contain "undefined behaviour" 

I guess I'm unsure of what you're getting at.  Even extremely diligent
programmers write code with bugs no matter what language they use.  C
has the particularly obnoxious characteristic that program bugs often
manifest as UB.  That's a problem with C, not with C compilers.

> For now the undefined behaviour problems I have seen seemed to be
> relatively local.

Hmm, maybe there is something to this, in cases where the programmer
misunderstands the language, like in the a[i]=i++ example.  Some of
these now generate compiler warnings, at least wih -Wall.  But there are
also things like integer overflow, where the programmer simply didn't
expect the number to go out of range, and it did so because of
unforeseen global properties of the program and its input data.

> compilers are usually worse than programmers at finding out something
> that's combined from faraway parts of the programs

That might not last.  Liquid Haskell and Spark Ada both already use SMT
solvers to check verification conditions.  It seems obvious that we'll
see whole-program optimizers working that way before long.  Those things
routinely solve systems with 1000's of variables to find connections
that humans can't possibly see.  Maybe tons more UB will surface in
existing programs when that happens.

Right now with GCC it's common to see a 3x speedup for C++ code from -O3
vs. no optimization.  That's probably because C++ style using lots of
template expansion, statically computable method lookups, etc. result in
straightforward (i.e. bloated and redundant) intermediate code generated
near the front end, that gets cleaned up by the optimization phases.
That is, doing a good job compiling idiomatic C++ code -requires- what
you call "compiler heroics" and the C++ idioms were designed in the
expectation that the optimizations would be present.

It could be that the extra optimizations of recent GCC vs. GCC 2.7 are
because recent versions are aimed at compiling boilerplate-heavy code
coming out of the C++ front end, while old GCC was a pure C compiler
whose input code was expected to more directly resemble the output.  But
with all those optimizations right there in the compiler, it's natural
that C code gets run through them too.

>>With a small program ...you can have a code review where multiple
>>programmers examine it in detail and really check everything, etc.
> Sure, but that has nothing to do with undefined behaviour.

It explains why you can hope for lower bug density in small programs
than big ones.

> When gcc turns a bounded loop that contains a out-of-bounds array read
> into an endless loop, then yes, that is miscompiled.

If you mean what I think you do, the compiler made a logical inference
from the program code based on the fact that valid programs don't do OOB
references.  The program did the reference anyway, breaking an invariant
that the compiler had relied on.  Turning off such inferences might not
have much performance cost for C code but I suspect it makes a much
bigger difference for C++.  So maybe that explains what's going on.  If
that's the situation, it might be reasonable to optionally back off the
optimizations for C.

> If, OTOH, a compiler compiles an out-of-bounds array access when the
> programmer writes an out-of-bounds array access, then the compiler is
> doing what programmer expects; 

That means the programmers don't understand the language, since OOB
references are specified to be UB.  And keep in mind how many C
programmers tend to be elitist and egotistical, saying subscript
checking is for weaklings and OOB errors only happen to programmers less
perfect than themselves, so it's fine if the compiler generates nasal
demons.  In that context those programmers really are getting what they
asked for.

> As for [OOB subscript] being one of the commonest forms, do you have
> numbers for that?  

At least 1 whole book has been written about them:
  www.amazon.com/dp/1932266674
The blurb claims: "over half of the 'SANS TOP 10 Software
Vulnerabilities' are related to buffer overflows.

> I would expect it to be relatively rare, because it usually is a bug
> even when compiled correctly.

Of course it's a bug, UB is always a bug, but there's no such thing as
an incorrect compilation of UB.  

> The specification in case of the C standard is incomplete, as is
> evidenced by the fact that nearly all C programs exhibit undefined
> behaviour

Nearly all big programs in any language have bugs.  It's just that C
program bugs result in UB a lot of the time, which means they have
potentially worse consequences and are harder to diagnose than
comparable bugs in programs written in other languages.  

> The proposed features of Regehr's friendly C sound reasonable.

Well, given your dissatisfaction with -fwrapv as a way of getting the
signed int overflow behavior you want, I don't think you'd be satisfied
with an -ffriendly option to enable friendly C.  You'd want it to be the
default, which I can go along with.  The next question is whether you'd
accept the existence of a -fhostile option to compile aggressively
presuming the absence of UB.  Because the way C programmers are, if they
experimentally try that flag and find it makes their program run 2%
faster, they're going to enable it in production and we're exactly where
we are now.  What then?

>>Me, I think C is hopeless ...
> Maybe you like miscompilation so much because you wish for C to vanish.

Hmm.  I do still write C code sometimes and I like doing it.  But I'd
say I'd like for it to be relegated to a mostly-historical niche,
something like where Forth is now.  Writing big critical programs in C
is just not wise.

>>It makes more sense to define a language that's completely free of UB
> You mean, a language like C#?  

Well, we're talking about low level languages, so I was thinking more
like Algol-60 or maybe Ada.  Even current idiomatic C++ is much safer
than C if you don't mind the code bloat.

> The student had to implement basic data structures of Postscript in
> relatively inefficient ways.

I'd expect most of the CPU time of real-world Postscript code is in font
rendering, so an efficiency hit in the high-level data structures isn't
likely to affect actual performance much.

> There is a need for low-level languages like C and Forth.

Yes, for sure.  These days outside embedded systems, it's often be
possible to write the outer levels of the program in HLL's and write the
performance critical parts at a lower level.

> BTW, why are array overruns more defensible than, say, left-shifting
> negative numbers?  Or other undefined behaviours?

I thought trapping subscript errors in C requires changing the data
representation, e.g. to use fat pointers, but it looks like -fsanitize
might somehow avoid this, hmm.

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

#38592

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>an awful lot of industry code... could truthfully be called sloppy.
>> Sure, but that's not the issue here.  As I wrote: Actually, even if
>> you are more diligent than typical in the industry, you can still
>> produce programs that contain "undefined behaviour" 
>
>I guess I'm unsure of what you're getting at.  Even extremely diligent
>programmers write code with bugs no matter what language they use.

What I am getting at is that you can write and debug a program, test
it with all kinds of tests and verify that the generated assembly code
is correct (the way that has been used for critical software), with
the result that the executable program has no bugs.  And yet the
program contains undefined behaviour according to the C standard.

>C
>has the particularly obnoxious characteristic that program bugs often
>manifest as UB.  That's a problem with C, not with C compilers.

A problem with current C compiler maintainers is that they try to
muddy the waters by not making a difference between bugs and undefined
behaviour.  The question is, what is your motivation for muddying the
waters in this way?

>> For now the undefined behaviour problems I have seen seemed to be
>> relatively local.
>
>Hmm, maybe there is something to this, in cases where the programmer
>misunderstands the language, like in the a[i]=i++ example.  Some of
>these now generate compiler warnings, at least wih -Wall.  But there are
>also things like integer overflow, where the programmer simply didn't
>expect the number to go out of range, and it did so because of
>unforeseen global properties of the program and its input data.

These don't lead to undefined-behaviour problems, because the compiler
does not see the overflow, either, and therefore compiles the program
as expected.

>> compilers are usually worse than programmers at finding out something
>> that's combined from faraway parts of the programs
>
>That might not last.  Liquid Haskell and Spark Ada both already use SMT
>solvers to check verification conditions.  It seems obvious that we'll
>see whole-program optimizers working that way before long.  Those things
>routinely solve systems with 1000's of variables to find connections
>that humans can't possibly see.  Maybe tons more UB will surface in
>existing programs when that happens.

I doubt it, but if it happens, all the worse (or better, if you wish
for C to vanish).  If the GCC maintainers keep their attitude, they
will then miscompile code based on undefined behaviour that humans
can't possibly see.

>Right now with GCC it's common to see a 3x speedup for C++ code from -O3
>vs. no optimization.  That's probably because C++ style using lots of
>template expansion, statically computable method lookups, etc. result in
>straightforward (i.e. bloated and redundant) intermediate code generated
>near the front end, that gets cleaned up by the optimization phases.
>That is, doing a good job compiling idiomatic C++ code -requires- what
>you call "compiler heroics" and the C++ idioms were designed in the
>expectation that the optimizations would be present.

No, compiler heroics is something else.  It's what compiler writers do
when the useful optimizations do not use an optimization opportunity
they see in a benchmark.  An example was one of the SPEC benchmarks
(ear IIRC) that used a bad access pattern; from the descriptions it
accesssed some field of a lot of structs first, then another field,
leading to low spatial locality and lots of cache misses.  Sun put in
heroic effort to recognize that in this particular program, the array
of structs could be rearranged into a struct of arrays and then did
it, and got a big speedup.  Of course, the check fails in nearly all
other cases where this kind of rearrangement would be beneficial.

What you describe is the exact opposite: Not the compiler being tuned
to benchmarks, but programmers writing their programs to make use of
the optimizations that the compilers have.  We have done so in Gforth:
GCC performs register allocation and optimizes many assignments
between local variables away, so I made use of that to make the
primitive generator simpler; as a result, the generated C code
contains many such assignments.  Similarly for the f2c Forth-to-C
compiler prototype; as a result, the benchmarks used for evaluating
f2c ran 4.92-9.35 times slower when compiled without optimization than
when compiled with optimization, by gcc-2.6.3, and run on a 486
<https://www.complang.tuwien.ac.at/forth/performance.html>.

So a 3x speedup of -O3 vs. no optimization is not particularly high or
new.

>It could be that the extra optimizations of recent GCC vs. GCC 2.7 are
>because recent versions are aimed at compiling boilerplate-heavy code
>coming out of the C++ front end, while old GCC was a pure C compiler
>whose input code was expected to more directly resemble the output.  But
>with all those optimizations right there in the compiler, it's natural
>that C code gets run through them too.

I guess that they added some proper optimizations to gcc since the 2.7
times, not just miscompilations.  It certainly seems to be more
aggressive with inlining, and that is a proper optimization that
probably helps your C++ boilerplate.

>> When gcc turns a bounded loop that contains a out-of-bounds array read
>> into an endless loop, then yes, that is miscompiled.
>
>If you mean what I think you do, the compiler made a logical inference
>from the program code based on the fact that valid programs don't do OOB
>references.  The program did the reference anyway, breaking an invariant
>that the compiler had relied on.  Turning off such inferences might not
>have much performance cost for C code but I suspect it makes a much
>bigger difference for C++.  So maybe that explains what's going on.  If
>that's the situation, it might be reasonable to optionally back off the
>optimizations for C.

I don't care what they do with C++ code.  That's between the C++
programmers and the C++ compiler maintainers.

>> If, OTOH, a compiler compiles an out-of-bounds array access when the
>> programmer writes an out-of-bounds array access, then the compiler is
>> doing what programmer expects; 
>
>That means the programmers don't understand the language, since OOB
>references are specified to be UB.

That means you don't understand C programmers.

>And keep in mind how many C
>programmers tend to be elitist and egotistical, saying subscript
>checking is for weaklings and OOB errors only happen to programmers less
>perfect than themselves, so it's fine if the compiler generates nasal
>demons.  In that context those programmers really are getting what they
>asked for.

Sure, such a programmer gets what they asked for.  I have never met
such a C programmer though, only miscompiler defenders that argue like
that.

>> As for [OOB subscript] being one of the commonest forms, do you have
>> numbers for that?  
>
>At least 1 whole book has been written about them:
>  www.amazon.com/dp/1932266674
>The blurb claims: "over half of the 'SANS TOP 10 Software
>Vulnerabilities' are related to buffer overflows.

Sure, it's a frequent vulnerability, and then it is a real bug (in the
executable program); but that says nothing about how frequent other
undefined behaviours are.  They are usually compiled as expected by
the compilers, and do not result in a bug (much less a vulnerability)
in the resulting program.

>> I would expect it to be relatively rare, because it usually is a bug
>> even when compiled correctly.
>
>Of course it's a bug, UB is always a bug, but there's no such thing as
>an incorrect compilation of UB.  

Nonsense.

>> The specification in case of the C standard is incomplete, as is
>> evidenced by the fact that nearly all C programs exhibit undefined
>> behaviour
>
>Nearly all big programs in any language have bugs.  It's just that C
>program bugs result in UB a lot of the time, which means they have
>potentially worse consequences and are harder to diagnose than
>comparable bugs in programs written in other languages.  

C programs exhibit undefined behaviour even in executions when the
executable program works correctly, e.g., when a compiler compiles an
empty program.  You trying to muddy the waters by conflating undefined
behaviour with real bugs is getting old.

>> The proposed features of Regehr's friendly C sound reasonable.
>
>Well, given your dissatisfaction with -fwrapv as a way of getting the
>signed int overflow behavior you want, I don't think you'd be satisfied
>with an -ffriendly option to enable friendly C.  You'd want it to be the
>default, which I can go along with.

-ffriendly would be much better than the current state of affairs
(rampant miscompilation), but would not help existing programs; they
would need to be changed to get the benefit of -ffriendly.  Therefore
making it the default would be even better.

>The next question is whether you'd
>accept the existence of a -fhostile option to compile aggressively
>presuming the absence of UB.  Because the way C programmers are, if they
>experimentally try that flag and find it makes their program run 2%
>faster, they're going to enable it in production and we're exactly where
>we are now.  What then?

They asked for a hostile compiler, they got it.  At least it would be
easy to fix it by removing -fhostile.

>> The student had to implement basic data structures of Postscript in
>> relatively inefficient ways.
>
>I'd expect most of the CPU time of real-world Postscript code is in font
>rendering, so an efficiency hit in the high-level data structures isn't
>likely to affect actual performance much.

Maybe.  I can imagine similar issues coming up in the font rendering
data structures, but don't know for sure (rendering was excluded from
the effort).  I would not be surprised, though, if most of the
Postscript executions these days did not use any rendering at all, but
just generate PDF.  I also remember an article in BYTE where the
author described doing interesting rendering things in Postscript that
blocked the typesetting machine at his print shop for 12 hours with
Postscript code execution, not with font rendering.  Anyway, if you
use Postscript as a programming language, not as a rendering language,
these things play a role.  And I guess that if you implement a
scripting language, you hit similar issues.

>> BTW, why are array overruns more defensible than, say, left-shifting
>> negative numbers?  Or other undefined behaviours?
>
>I thought trapping subscript errors in C requires changing the data
>representation, e.g. to use fat pointers, but it looks like -fsanitize
>might somehow avoid this, hmm.

What is -fsanitize?  And what does "trapping subscript errors" have to
do with whether array overruns are more defensible than other
undefined behaviours?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#38593

In article <2015Apr25.103651@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Paul Rubin <no.email@nospam.invalid> writes:
>>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
<SNIP>
>
>>> As for [OOB subscript] being one of the commonest forms, do you have
>>> numbers for that?
>>
>>At least 1 whole book has been written about them:
>>  www.amazon.com/dp/1932266674
>>The blurb claims: "over half of the 'SANS TOP 10 Software
>>Vulnerabilities' are related to buffer overflows.
>
>Sure, it's a frequent vulnerability, and then it is a real bug (in the
>executable program); but that says nothing about how frequent other
>undefined behaviours are.  They are usually compiled as expected by
>the compilers, and do not result in a bug (much less a vulnerability)
>in the resulting program.

No, buffer overflow is not a bug in the executable program.
For example. I have a program to turn text files into blocks.
I read in the lines in a 1024 char buffer. That should be ample.
This is a tradeoff. I just don't go to the trouble of trading
a crash for an error message. Mine is typical c-programmer
behaviour. With the right input the program can be crashed,
and I accept that.

Now if Microsoft uses that attitude in their browser for possible
malicious input with dire consequences, that may be considered a
defect. But the language per se allows to trade speed for safety.
(What about my euler problems? They take long enough without
a manually built in bounds checking.)

Even if the program ends with a buffer overflow message? Is that
a bug in the executable program? Possibly but not necessarily.
A programmer can decide to have the language catch extremely
improbably, 99.99% sure malicious input. A user is confronted with
a mystery, but no virus.

For sure it is the most occurring fault. Nearly all my faulty algol60
programs ended with "array index out of bounds".

<SNIP>
>
>- anton

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#38595

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2015Apr25.103651@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>Paul Rubin <no.email@nospam.invalid> writes:
>>>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
><SNIP>
>>
>>>> As for [OOB subscript] being one of the commonest forms, do you have
>>>> numbers for that?
>>>
>>>At least 1 whole book has been written about them:
>>>  www.amazon.com/dp/1932266674
>>>The blurb claims: "over half of the 'SANS TOP 10 Software
>>>Vulnerabilities' are related to buffer overflows.
>>
>>Sure, it's a frequent vulnerability, and then it is a real bug (in the
>>executable program); but that says nothing about how frequent other
>>undefined behaviours are.  They are usually compiled as expected by
>>the compilers, and do not result in a bug (much less a vulnerability)
>>in the resulting program.
>
>No, buffer overflow is not a bug in the executable program.

A buffer overflow that results in a vulnerability is seen as a bug by
most programmers.

Whether not protecting against a buffer overflow in a program that
gets only input from a trusted source and does not do anything
critical is a bug is up for the programmer and the user to decide
(it's certainly not a mark of a top-quality program).  They often are
considered bugs when they happen, whereas a left-shift of a negative
number that is compiled as expected (as left shift) is very rarely
considered a bug by the programmer or the user.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#38369

In article <87pp73wi24.fsf@jester.gateway.pace.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>krishna.myneni@ccreweb.org writes:
>> Interestingly, gcc 4.9 does not complain at all about a statement like
>>    a[i] = i++;
>> It compiles and executes without problem, per the example below.
>
>The statement has undefined semantics, which means the compiler can do
>whatever it wants, including doing what you expected it to do, as it did
>there.  It's just not -required- to do what you expected, and the
>behavior can change from one compiler or compilation to another.  This
>is one of the reasons C sucks so bad.
>
>If you compile with -Wall you should get a warning message about that
>operation.

If someone still doubts this is sloppy code. Lets try Forth

: array CREATE CELLS ALLOT DOES> CELLS + ;

10 array a

: := SWAP ! ;

VARIABLE i

: ++ >R    R@ @   1 R> +! ;

i @ a  i ++ :=

In a language where everything happens under the hood,
that is an accident waiting to happen:

What was that again?

i @ a     i ++   SWAP !

That's stupid, let's make it

i ++    i @ a    !

The original example with the *sp++ is even more convincing.

: *++  >R  R@ @    1 CELLS R> +! ;

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#38400

On Sunday, April 19, 2015 at 5:08:56 AM UTC-5, Albert van der Horst wrote:
> In article <87pp73wi24.fsf@jester.gateway.pace.com>,
> Paul Rubin  <no.email@nospam.invalid> wrote:
> >krishna.myneni@ccreweb.org writes:
> >> Interestingly, gcc 4.9 does not complain at all about a statement like
> >>    a[i] = i++;
> >> It compiles and executes without problem, per the example below.
> >
> >The statement has undefined semantics, which means the compiler can do
> >whatever it wants, including doing what you expected it to do, as it did
> >there.  It's just not -required- to do what you expected, and the
> >behavior can change from one compiler or compilation to another.  This
> >is one of the reasons C sucks so bad.
> >
> >If you compile with -Wall you should get a warning message about that
> >operation.
> 
> If someone still doubts this is sloppy code. Lets try Forth
> 
> : array CREATE CELLS ALLOT DOES> CELLS + ;
> 
> 10 array a
> 
> : := SWAP ! ;
> 
> VARIABLE i
> 
> : ++ >R    R@ @   1 R> +! ;
> 
> i @ a  i ++ :=
> 
> In a language where everything happens under the hood,
> that is an accident waiting to happen:
> 
> What was that again?
> 
> i @ a     i ++   SWAP !
> 
> That's stupid, let's make it
> 
> i ++    i @ a    !
> 

It's not sloppy code. You performed a sloppy translation by assuming that the second Forth version is equivalent to the first. You could, however, have written, more appropriately,

   i ++ dup a !

which would have preserved the meaning. Doing a literal translation of C to Forth will get you into trouble very quickly.

Krishna

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

#38413

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>krishna.myneni@ccreweb.org writes:
>>>    a[i] = i++;
...
>If someone still doubts this is sloppy code. Lets try Forth
>
>: array CREATE CELLS ALLOT DOES> CELLS + ;
>
>10 array a
>
>: := SWAP ! ;
>
>VARIABLE i
>
>: ++ >R    R@ @   1 R> +! ;
>
>i @ a  i ++ :=
>
>In a language where everything happens under the hood,
>that is an accident waiting to happen:
>
>What was that again?
>
>i @ a     i ++   SWAP !
>
>That's stupid, let's make it
>
>i ++    i @ a    !

So, you have two different Forth programs that behave differently.
How is that supposed to show anything about the sloppyness of one C
program that behaves differently when compiled with gcc-4.8 compared
to gcc-4.7?

Interestingly, your Forth program is non-standard: It fails to
initialize I.  I have tested a number of Forth systems (Gforth, VFX,
SwiftForth. iforth-2.1, SP-Forth) with

variable x x @ .

and they all output "0"; looking at the decompilation of VARIABLE in
Gforth, VFX, and SwiftForth, the 0 comes from explicit initialization,
not by accident. So with these systems you would never have detected
the non-standardness by testing.  Is your code sloppy?  Would it be a
good idea for these Forth systems to change VARIABLE to allot memory
without initializing it in the next release?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#38464

Anton Ertl wrote:
> and they all output "0"; looking at the decompilation of VARIABLE in
> Gforth, VFX, and SwiftForth, the 0 comes from explicit initialization,
> not by accident. So with these systems you would never have detected
> the non-standardness by testing.  Is your code sloppy?  Would it be a
> good idea for these Forth systems to change VARIABLE to allot memory
> without initializing it in the next release?

Or rather deliberately initialize it with random garbage?

There's a reason why all these Forths you looked at zero-initialize 
variables: It makes the program behave deterministic.  The question is: 
should we put this into the standard?  The first thing I make when using 
allocate is to define an alloz, which gives me an erased block.  ALLOCATE is 
about the only way in Gforth to get at uninitialized memory.  For larger 
blocks, ERASE might be too costly, but then, there's a Unix way to allocate 
big chunks of zero-initialized memory at much lower cost: mmap().

In general, undefined behavior is bad.  Especially when it is "mostly 
defined".  If you had a VARIABLE with CELL ALLOT instead of 0 , in Gforth, 
it would normally result in a 0 content, too.  Unless you use MARKER.  We, 
the developers of Gforth, don't use MARKER a lot.  So if we write our code 
with our way of cleaning up Gforth (by restarting it), we would never see a 
problem.  Users who use MARKER more than we do would find bugs.  So the 
solution is to make that behavior defined, at least within Gforth.  VFX and 
SwiftForth have done the same thing.  It's sane, and IMHO, it should be 
standardized as part of our effort to tighten the standard where common 
practice has emerged.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

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

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

csiph-web