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

Groups > comp.lang.forth > #38589

Re: rhel 7 and kforth

Show all headers | View raw

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.

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web