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

Groups > comp.lang.forth > #38494

Re: rhel 7 and kforth

Show all headers | View raw

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/

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