Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #56795
| Newsgroups | comp.lang.forth |
|---|---|
| Date | 2017-04-06 17:10 -0700 |
| References | (7 earlier) <cdc8055a-160a-46e4-a466-e289edfe1e45@googlegroups.com> <e5a4671c-9847-4940-b089-d0c08260c175@googlegroups.com> <CZednRNE7OwXiHjFnZ2dnUU7-QudnZ2d@supernews.com> <cf7e8f98-9839-4faa-b734-8e0ad9f8d1d1@googlegroups.com> <IAqFA.243119$0L.131983@fx12.am4> |
| Message-ID | <e159e6aa-1237-4bfb-8891-4bb144dd34bb@googlegroups.com> (permalink) |
| Subject | Re: LLVM and Forth |
| From | Joel Rees <joel.rees@gmail.com> |
On Thursday, April 6, 2017 at 9:33:45 PM UTC+9, Spiros Bousbouras wrote:
> Since this has become about C now , I'm crossposting to comp.lang.c
> and setting follow-ups to the same.
I'm using Google groups because I'm lazy, so I have no idea whether this will maintain the cross-post.
> On Wed, 5 Apr 2017 20:14:27 -0700 (PDT)
> krishna(something)@(something).(something) wrote:
> > It's a matter of trusting the compiler will code what you ask it to do,
> > and understanding the cases of undefined behavior when the compiler may
> > not generate expected code. It's not clear to me that mere mortals can
> > keep track of all of the cases of UB in the C standard, and the latitude
> > given to compilers to do different things in those cases.
>
> I'm a mere mortal and I can certainly keep track of UB relevant to the code
> I write. In most cases it's actually common sense. For example I don't need
> to consult the C standard to know that trying to read beyond the bounds of
> an array will probably not result in anything useful because , even *conceptually*
> (i.e. without referring to the standard of any specific language) , it doesn't
> make sense. Perhaps the confusion arises because some people when programming
> in C are not thinking in terms of C but in terms of assembly. So they translate
> mentally the C code in some generic assembly instructions and then try to decide
> if the C code does something meaningful based on what those hypothetical assembly
> instructions will do.
>
> Example : the expression array[i] where i is beyond the end of the array.
The problem here is knowing whether your loop properly accesses the first and last elements of an array. Too many programmers are too lazy to understand the concept of where the exit comes in a loop, and too lazy to learn to track the state of the variables relevant to the loop control.
"Undefined Behavior" has two meanings here. Perhaps the C standard should have said "undefinable behavior", but that has certain potential misinterpretations as well.
> Thinking in terms of C : Not defined which means you aren't going to get anything
> useful so you shouldn't use it.
That's the approach Anton seems to be rather militant about. (And I don't blame him.)
But it's actually a third meaning for UB.
According to a common-sense interpretation (unless you are one who spews demons from your nose when faced with code that does not generalize well in certain corner-cutting hardware contexts), the standard defines UB as having the potential to be mean something different or nothing at all in certain contexts that the standards committee chose to accept as permissible relative to the standard, mostly because of the charismatic influence of the practitioners of said hardware.
("Charismatic" here refers to the sort of the charisma that includes the Kim family among leaders who rule by "charisma".)
> Pondering or testing what's the most crazy thing
> which might happen , may be a bit of fun every now and again but is not relevant to
> practical programming.
Being unable to specify target hardware is another way to invite bugs.
> Thinking in terms of assembly : "array[i] will be translated into an assembly
> instruction which calculates an address of the form base + i * constant .
> This will always point into some address in memory so I should get some value
> or at least a segmentation fault ; so not a totally unpredictable result."
Some people conflate segmentation fault with UB, partly, we might guess, because they do not understand why, uhm, segmentation should fault. ;->
> Note first that not thinking in terms of C is more complicated and requires more
> knowledge than thinking in terms of C.
I'm not sure I could agree with this. Current "standard" C is way more complicated than most of the practitioners thereof have any idea.
> Second , if one wants to think in terms of
> assembly then , from a practical point of view , it makes sense to program in
> assembly , not C.
Hear! Hear!
(Which is what attracts some people to Forth, really.)
> > Certainly coding guidelines, e.g. NASA's C coding guidelines (ref. 1) can
> > help avoid such difficulties. But, it's also clear that mere mortal
> > programmers may be easily confused.
No one who claims to be an engineer should ever refer to him/herself as a mere mortal as an excuse for not understanding the tools he or she as fully as possible.
Sure, it easily becomes idolatry, and is among the sins of society, to require certain occupations to operate in hero mode, but if engineers don't operate in hero mode, airplanes fall from the sky, etc.
> > See the old thread on comp.std.c (ref. 2).
> > Even some of the experts had problems with the interpretation of the standard;
> > but, to be fair, that's an old thread.
>
> [ References are
> 1. http://sdtimes.com/nasas-10-rules-developing-safety-critical-code
> and
> 2. https://groups.google.com/d/msg/comp.std.c/9lYbeLVaZCA/__behqP09dIJ
> ]
>
> Regarding the NASA guidelines , they are unsuitable for a lot of desktop software.
> For example "Do not use dynamic memory allocation after initialization." .How
> are you going to implement for example the Unix sort utility without using
> realloc() (depending on the size of the input) ?
>
> Your second reference has
> char *index;
> ....
> *index++ = toupper(*index);
>
> .He doesn't explain why he decided to write code like this as opposed to
> *index = toupper(*index);
> index++ ;
>
> .The latter seems to me more readable. So unless he had good reasons to prefer the
> first version then worrying whether it's undefined behaviour is irrelevant for
> programming ; one simply shouldn't write code like this.
I'll say amen to that, too.
I used to be a fan of auto-increment modes, but then I realized how many times I had been writing i++ when I really meant ++i, just because some pedant was scared of surprising later programmers with an idiom that wasn't probably taught in schools. (And ten years later, those who breath demons have finally begun to recognize that i = i + 1 in a C program is ++i, not i++. And get too excited about the fact.)
> Do you have an example
> of C code which satisfies the following 3 criteria ?
>
> 1. Is not contrived (according to your judgement).
> 2. You are not sure whether it has defined behaviour.
> 3. You do not see an obvious and easy way to change it so that it does what you
> want *and* doesn't look contrived (according to your judgement) *and* you are
> sure is not undefined behaviour.
I'm a late-comer to the conversation, but I have a few sitting around in my piles of old code.
I remember being excited to recognize that the reason my old assembler for the 6800, which I had written in college, was failing to run on my modern stuff was that I had, without realizing it, depended on a run-time semantic of dereferencing a NULL pointer. That one I understand now. But I know there are still dark corners hiding in code that I think I understand.
Yes, illuminating those dark corners is important. But it would be nice for the drunk policeman to allow me to continue looking where they wallet fell, rather than insist that I look under the lamp where there is light. So to speak.
> > I intend to continue using the GNU C++ and C compilers, but with -O0 and
> > -Wall flags turned on. Some of the code it generates at -O0 is fairly ugly,
> > but I expect it's reliable when the source is not UB.
>
> I don't think the -O0 part makes sense. If the compiler has bugs and miscompiles
> correct code then you want to find this out as early as possible rather than at a
> later point where you many need a higher optimisation level because otherwise the
> code does not run fast enough. If your code has undefined behaviour then if it does
> what you want then it's only by coincidence and your luck may run out even if you
> always use -O0 .So in my opinion , one should at least conduct some tests with
> other optimisation levels (and preferably using multiple compilers) to see if the
> code continues to run correctly.
Wish management would be more willing to put up with this kind of exploration, but that almighty false proxy of value is the bottom line.
> --
> Every application has an inherent amount of irreducible complexity. The only
> question is: Who will have to deal with it\u2014the user, the application
> developer, or the platform developer?
> http://www.nomodes.com/Larry_Tesler_Consulting/Complexity_Law.html
--
Joel Rees
http://reiisi.blogspot.com
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 06:36 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-01 14:57 +0000
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 11:55 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-02 15:24 +0000
Re: LLVM and Forth rickman <gnuarm@gmail.com> - 2017-04-01 11:21 -0400
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 11:57 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-02 04:02 -0500
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-02 06:35 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-02 14:41 +0000
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 01:09 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-03 05:32 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 13:52 +0000
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 07:59 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 16:08 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 12:22 -0500
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-03 20:10 -0700
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 22:19 -0700
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 16:12 +0200
Re: LLVM and Forth Walter Banks <walter@bytecraft.com> - 2017-04-05 17:27 -0400
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 14:29 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 03:17 -0500
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 05:04 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 12:55 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 10:08 -0500
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 17:05 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-04 11:29 -0500
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 19:11 +0200
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-04 21:29 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-05 15:01 +0000
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-05 18:42 +0100
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 04:01 -0500
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 18:48 +0000
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-06 18:42 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-07 04:02 -0500
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 21:18 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 22:43 +0000
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 20:54 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-09 14:53 +0000
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 00:38 +0000
Re: LLVM and Forth James Kuyper <jameskuyper@verizon.net> - 2017-04-09 22:46 -0400
Re: LLVM and Forth Robert Wessel <robertwessel2@yahoo.com> - 2017-04-09 22:27 -0500
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 12:36 +0000
Re: LLVM and Forth Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-10 14:09 +0100
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 13:07 +0000
Re: LLVM and Forth Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-10 16:18 +0100
Re: LLVM and Forth "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-10 11:51 -0400
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-12 21:32 +0000
Re: LLVM and Forth "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-12 18:29 -0400
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-12 15:29 -0700
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-13 02:55 +0200
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-10 18:38 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-10 11:54 -0500
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-10 10:17 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 17:02 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 10:03 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 03:25 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-04 11:24 +0000
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 04:55 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-04 12:28 +0000
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-04 16:16 +0000
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 15:38 +0200
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 16:06 +0200
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 17:57 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-05 00:44 -0400
Re: LLVM and Forth minforth@arcor.de - 2017-04-05 00:00 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 08:47 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-05 11:04 -0500
Re: LLVM and Forth john <anon@example.com> - 2017-04-05 18:04 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-05 13:04 -0700
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-05 18:20 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 20:14 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 12:33 +0000
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 10:49 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 18:55 +0100
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 20:41 +0000
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 21:47 +0100
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 21:56 +0100
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 23:59 -0400
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-06 17:10 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-07 03:33 -0400
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 22:48 +0000
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-09 15:06 -0400
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 22:45 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-09 14:27 +0000
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-09 21:26 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-09 13:35 -0400
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-09 14:07 -0700
Re: LLVM and Forth minforth@arcor.de - 2017-04-05 12:16 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 20:27 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 05:24 -0400
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 03:26 -0700
Re: LLVM and Forth minforth@arcor.de - 2017-04-06 04:05 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 06:50 -0500
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 05:23 -0400
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 04:44 -0500
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 10:57 +0100
Re: LLVM and Forth peter.m.falth@gmail.com - 2017-04-05 05:29 -0700
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-14 02:04 +0000
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 14:03 +0200
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-16 00:44 +0000
Re: LLVM and Forth alex@rivadpm.com - 2017-04-16 05:53 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-16 15:43 +0000
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-16 22:27 +0000
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-18 02:45 +0200
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-18 18:26 +0100
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-20 19:51 +0200
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 19:08 +0100
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-20 20:42 +0200
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 20:29 +0100
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 20:48 +0100
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-21 11:49 +0000
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-03 20:39 -0400
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-02 21:15 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-02 15:18 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 13:07 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 09:45 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 22:52 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 15:25 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 09:35 +0100
Re: LLVM and Forth antispam@math.uni.wroc.pl - 2017-04-06 01:36 +0000
Re: LLVM and Forth minforth@arcor.de - 2017-04-05 22:00 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 09:52 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-06 20:15 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-03 05:20 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 17:11 +0100
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 17:43 +0100
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 10:53 -0700
csiph-web