Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #45809 > unrolled thread
| Started by | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| First post | 2016-03-03 16:24 -0800 |
| Last post | 2016-03-18 17:45 +0000 |
| Articles | 20 on this page of 108 — 21 participants |
Back to article view | Back to comp.lang.forth
OT: One of Anton's papers makes Hacker News Paul Rubin <no.email@nospam.invalid> - 2016-03-03 16:24 -0800
Re: OT: One of Anton's papers makes Hacker News Julian Fondren <julian.fondren@gmail.com> - 2016-03-03 21:06 -0800
Re: OT: One of Anton's papers makes Hacker News Ron Aaron <rambamist@gmail.com> - 2016-03-04 07:18 +0200
Re: OT: One of Anton's papers makes Hacker News Paul Rubin <no.email@nospam.invalid> - 2016-03-03 21:33 -0800
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-04 17:52 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-04 12:32 +0000
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-04 18:20 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-05 02:23 +0000
Re: OT: One of Anton's papers makes Hacker News hughaguilar96@gmail.com - 2016-03-04 19:06 -0800
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-05 20:32 -0500
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-06 11:28 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-06 18:02 +0000
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 23:55 +0000
Re: OT: One of Anton's papers makes Hacker News hughaguilar96@gmail.com - 2016-03-06 14:48 -0800
Re: OT: One of Anton's papers makes Hacker News Julian Fondren <julian.fondren@gmail.com> - 2016-03-07 03:36 -0800
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-07 19:19 -0500
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 17:40 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-05 03:35 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-05 13:37 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-05 15:42 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 00:50 +0000
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-05 20:33 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 02:01 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-06 11:57 +0000
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-07 07:35 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-07 12:40 +0000
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-07 19:20 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-08 00:49 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-06 02:20 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-07 00:35 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-07 02:53 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-07 16:07 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-08 05:17 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-08 22:01 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-09 03:14 -0600
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-09 11:17 +0000
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-09 23:58 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-10 04:45 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-10 11:39 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-10 13:29 +0000
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 16:02 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-10 08:22 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 15:49 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-12 13:35 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-10 21:58 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-11 06:11 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-12 00:05 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-12 04:23 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 12:05 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-12 08:36 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 16:57 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-12 13:44 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 14:29 +0000
Re: OT: One of Anton's papers makes Hacker News "Elizabeth D. Rather" <erather@forth.com> - 2016-03-11 15:02 -1000
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 16:20 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-12 13:53 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-06 13:02 +0000
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-06 11:52 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-06 12:42 -0600
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-06 13:12 -0600
Re: OT: One of Anton's papers makes Hacker News Ron Aaron <rambamist@gmail.com> - 2016-03-04 07:20 +0200
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-04 17:37 +0000
Re: OT: One of Anton's papers makes Hacker News Julian Fondren <julian.fondren@gmail.com> - 2016-03-04 11:23 -0800
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-09 03:24 -0600
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-04 21:01 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-05 13:51 +0000
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-05 19:43 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 01:45 +0000
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-07 19:19 -0500
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 17:24 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-13 12:27 +0000
Re: OT: One of Anton's papers makes Hacker News raltbos@xs4all.nl (Richard Bos) - 2016-03-13 13:50 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-13 19:52 +0000
Re: OT: One of Anton's papers makes Hacker News Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-03-13 16:08 -0400
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-13 13:40 -0700
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-14 00:41 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-13 18:23 -0700
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-14 02:59 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-13 20:29 -0700
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-14 22:44 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-14 16:23 -0700
Re: OT: One of Anton's papers makes Hacker News Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-03-14 23:55 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-14 17:19 -0700
Re: OT: One of Anton's papers makes Hacker News Robert Wessel <robertwessel2@yahoo.com> - 2016-03-14 19:26 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-15 00:48 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-14 22:30 -0700
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-15 07:23 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-15 10:09 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-15 08:56 -0700
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-15 19:33 +0000
Re: OT: One of Anton's papers makes Hacker News Rosario19 <Ros@invalid.invalid> - 2016-03-17 09:46 +0100
Re: OT: One of Anton's papers makes Hacker News Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-17 09:37 -0400
Re: OT: One of Anton's papers makes Hacker News Rosario19 <Ros@invalid.invalid> - 2016-03-17 18:40 +0100
Re: OT: One of Anton's papers makes Hacker News Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-17 13:53 -0400
Re: OT: One of Anton's papers makes Hacker News invalid <address@is.invalid> - 2016-03-17 18:00 +0000
Re: OT: One of Anton's papers makes Hacker News Rosario19 <Ros@invalid.invalid> - 2016-03-17 18:37 +0100
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-18 14:36 +0000
Re: OT: One of Anton's papers makes Hacker News David Brown <david.brown@hesbynett.no> - 2016-03-14 09:17 +0100
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-14 22:56 +0000
Re: OT: One of Anton's papers makes Hacker News Robert Wessel <robertwessel2@yahoo.com> - 2016-03-14 20:00 -0500
Re: OT: One of Anton's papers makes Hacker News David Brown <david.brown@hesbynett.no> - 2016-03-15 11:22 +0100
Re: OT: One of Anton's papers makes Hacker News raltbos@xs4all.nl (Richard Bos) - 2016-03-14 22:38 +0000
Re: OT: One of Anton's papers makes Hacker News Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-03-14 01:40 -0500
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-06 11:00 +0000
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-07 19:19 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-08 01:02 +0000
Re: OT: One of Anton's papers makes Hacker News Julian Fondren <ayrnieu@gmail.com> - 2016-03-14 07:29 -0700
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-18 17:45 +0000
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-03-03 16:24 -0800 |
| Subject | OT: One of Anton's papers makes Hacker News |
| Message-ID | <87bn6vytsf.fsf@nightsong.com> |
Under the title "what every compiler writer should know about programmers". The paper criticizes various compiler responses to the presence of undefined behaviour in C programs, a topic that has come up here in CLF several times. Paper: http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf HN thread: https://news.ycombinator.com/item?id=11219874
[toc] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-03-03 21:06 -0800 |
| Message-ID | <10dd2a71-684a-4040-a497-e921feb5c575@googlegroups.com> |
| In reply to | #45809 |
On Thursday, March 3, 2016 at 6:24:18 PM UTC-6, Paul Rubin wrote: > Under the title "what every compiler writer should know about > programmers". The paper criticizes various compiler responses to the > presence of undefined behaviour in C programs, a topic that has come up > here in CLF several times. > > Paper: > http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf > > HN thread: > https://news.ycombinator.com/item?id=11219874 Interesting posts: marvy: I don't think he's being tongue in cheek. I bet you he's genuinely angry and resentful. From his point of view, he once had a lovely language, C*, and he can't use it any more, and is being forced into assembly instead, for no reason other than the perversity of the maintainers of the only two C compilers that he feels that he can use. tytso: It may be unpleasant, but the reality is that many programmers do feel that way. I can say that as a kernel programmer, I approach using a new version of gcc with a particular version of dread. What sort of random bugs that might end up causing kernel crashes or data corruption will arise when I try using a new compiler? As a result, I'm quite sympathetic to the attitude of "any sufficiently advanced compiler is indistinguishable from a malicious adversary".... Gibbon1: I'm just a crummy engineer that writes a fair amount of embedded firmware. When this subject comes up I've found mainstream programmers attitude towards these sorts of concerns to be actually hostile. A lot of programmers think when specification gives the compile maintainers a choice between making the code do something platform specific or something silently malicious, to do the malicious thing in order to 'teach the programmer a lesson' I'm with you. These guys aren't helping us, our customers or the people that pay the bills. WalterBright (reminding me of Factor et al.): It's really, really hard to sell someone on a non-standard implementation of a popular language like C. For example, I've had customers beg me to add an extension to C. I implement it, and present it to them. They refuse to use it - because then their code would be dependent on a non-Standard feature. The solution (for me, anyway) was to create an entirely new language. The changes that nobody wanted in C (not because they were bad, but because they were non-Standard) found plenty of traction and users in D. and others: My reaction was to stop coding in C. ... ... I spend my energy investing in staying the hell away from C when possible. ... ... if I had to do embedded work, I would use Ada. eru (in reply to the last, about Ada): Or even use an explicit C-like dialect that defines more things, if you like the syntax. Wouldn't it be nice if you could just use C and assume more things, and not have the rug pulled out from under you by a hostile compiler? Wouldn't that be *even better* than finding a non-C language that's as C-like as possible while "defining more things"? There are a few other posts that you can read without catching some kind of exotic disease, but not many. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2016-03-04 07:18 +0200 |
| Message-ID | <nbb5lo$n0l$2@dont-email.me> |
| In reply to | #45810 |
On 04/03/2016 07:06, Julian Fondren wrote: > There are a few other posts that you can read without catching > some kind of exotic disease, but not many. Try posting on reddit some time if you really want to catch an exotic disease.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-03-03 21:33 -0800 |
| Message-ID | <877fhizu1u.fsf@nightsong.com> |
| In reply to | #45810 |
Julian Fondren <julian.fondren@gmail.com> writes: > Wouldn't it be nice if you could just use C and assume more > things, and not have the rug pulled out from under you by a > hostile compiler? Wouldn't that be *even better* than finding > a non-C language that's as C-like as possible while "defining > more things"? That turns out to be much harder than it sounds. John Regehr was supportive of such an effort, but eventually decided it wasn't practical. It's not just a matter of "defining things" but also how to get the program to detect the conditions that trigger the UB and do something "defined" instead. I've fooled with Ada a little bit and liked it. I haven't yet seen any knowledgeable comparisons between Ada and Rust, but would like to.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-04 17:52 +0000 |
| Message-ID | <2016Mar4.185250@mips.complang.tuwien.ac.at> |
| In reply to | #45814 |
Paul Rubin <no.email@nospam.invalid> writes:
>Julian Fondren <julian.fondren@gmail.com> writes:
>> Wouldn't it be nice if you could just use C and assume more
>> things, and not have the rug pulled out from under you by a
>> hostile compiler? Wouldn't that be *even better* than finding
>> a non-C language that's as C-like as possible while "defining
>> more things"?
>
>That turns out to be much harder than it sounds. John Regehr was
>supportive of such an effort, but eventually decided it wasn't
>practical. It's not just a matter of "defining things" but also how to
>get the program to detect the conditions that trigger the UB and do
>something "defined" instead.
What is hard is to get a consensus on how to define things if you want
to go there. But what I learned and, I think, John Regehr also
learned, is that it is actually not necessary for most programs to
actually define things at the language specification level.
What is necessary for most programs is a certain consistency in
implementation. E.g., if a signed addition performs a 2s-complement
wrap-around addition in the general case on the platform (hardware,
compiler, etc.), then the compiler should preserve that behaviour as
far as observable behaviour goes, across optimization levels and
compiler versions; if *p does a memory access that deals with
unaligned addresses in a certain way in the general case, then it
should behave the same way across optimization levels and compiler
versions.
I don't think it's necessary to refine the specification for that (and
John Regehr came to the same conclusion AFAICS), but it needs an
attitude change among C compiler maintainers.
Concerning implementation, that is actually easier than what they are
doing now; where they now derive "facts" about programs based on the
assumption that the program does not perform undefined behaviour,
leave that check away and don't derive such "facts", and the compiler
will automatically generate the code for the general case. There are
a few special cases where something else is required, e.g., using
unaligned instead of aligned SIMD instructions for auto-vectorized
code on AMD64, but overall a compiler that does not do nasal demon
"optimizations" is easier to write than one that does.
Of course, if they want to keep nasal demon "optimizations" as a
option, the overall result is more complex, but that's due to the
decision to also offer nasal demon "optimizations".
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-03-04 12:32 +0000 |
| Message-ID | <56d98052$0$24143$e4fe514c@news.xs4all.nl> |
| In reply to | #45810 |
Julian Fondren <julian.fondren@gmail.com> writes: >On Thursday, March 3, 2016 at 6:24:18 PM UTC-6, Paul Rubin wrote: >> Under the title "what every compiler writer should know about >> programmers". The paper criticizes various compiler responses to the >> presence of undefined behaviour in C programs, a topic that has come up >> here in CLF several times. >> >> Paper: >> http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf >> >> HN thread: >> https://news.ycombinator.com/item?id=11219874 >Interesting posts: >marvy: > I don't think he's being tongue in cheek. I bet you he's > genuinely angry and resentful. From his point of view, he once > had a lovely language, C*, and he can't use it any more, and is > being forced into assembly instead, for no reason other than the > perversity of the maintainers of the only two C compilers that > he feels that he can use. <similar reactions deleted> I've been a professional c programmer for decades. I can't sympathize with the examples of signed int x; ... x-1>x .. and for (...... :dd[++k]) where the last access is outside the array bounds of dd. They are just bad code, that I would never write. My reputation for writing solid code probably derives from that. Think of it this way. If you rephrase it in Ada (or another decent "european" protective language), you would get integer overflow and array access out of bounds in running the program. The interesting thing is that this is exactly the type of protection Anton Ertl wants to add to Forth. Maybe the attitude of "I want to write assembly language using C." "I want to write assembly language using Forth" is past the times. I see the example of wheezy. "Half of the sources of packages exhibit this type of behaviour." I see it differently, the other half of the packages are truly professionally written. Not bad, given the volunteer origin of wheezy. >There are a few other posts that you can read without catching >some kind of exotic disease, but not many. Huh? > >-- Julian -- 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]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-04 18:20 +0000 |
| Message-ID | <2016Mar4.192044@mips.complang.tuwien.ac.at> |
| In reply to | #45826 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>I've been a professional c programmer for decades.
>
>I can't sympathize with the examples of
> signed int x;
> ...
> x-1>x
> ..
>and
> for (...... :dd[++k])
>where the last access is outside the array bounds of dd.
>
>They are just bad code, that I would never write.
"I would never write this kind of bad code [so miscompiling it is fine
with me]" is a reaction some have when discussing this topic.
Would you also never write
a[a[i]]=1;
?
>Think of it this way. If you rephrase it in Ada (or another
>decent "european" protective language), you would get
> integer overflow
Please show me your implementation of WITHIN in one of your Forth
systems.
>and
> array access out of bounds
>in running the program.
>
>The interesting thing is that this is exactly the type of protection
>Anton Ertl wants to add to Forth.
I don't want to add integer overflow trapping to Forth; on the
contrary, I proposed <http://www.forth200x.org/twos-complement.html>,
which specifies modulo arithmetics. If someone thinks that integer
overflow checking is particularly useful, feel free to propose it, but
don't do it for + - * (Ulrich Hoffmann has given a talk at a
Forth-Tagung about such a thing).
Concerning bounds-checked array accesses, yes, I have discussed about
how to do such things in Forth. In that case, when there is an
out-of-bounds access, there would be an error (probably an exception);
that's quite different from miscompiling the (bounded) loop into an
infinite loop.
>Maybe the attitude of
>"I want to write assembly language using C."
>"I want to write assembly language using Forth"
>is past the times.
No, it's actually the position I take in that paper, and that's why I
think the attitude "I don't write such code, so miscompile away" is
not appropriate. The stuff discussed in the memory access
vulnerability thread would be for when people want a more restricted
(maybe Ada-like) language in some parts of the program, to make the
checking easier.
>I see the example of wheezy. "Half of the sources of packages
>exhibit this type of behaviour." I see it differently,
>the other half of the packages are truly professionally written.
Not quite sure what you mean with "truly professionally written", but
if you mean the absence of undefined behaviour, no, Wang et al.'s
paper does not say that. It just says that their static checker did
not find any cases in these packages where it could see that a
nasal-demon "optimizing" compiler might miscompile the code by
"optimizing" checks away. There can still be lots of undefined
behaviours in a run of programs in these packages, including, e.g.,
buffer overflow vulnerabilities. There might also be cases where a
nasal-demon "optimizing" compiler might miscompile these programs in
other ways than by "optimizing" a check away.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-03-05 02:23 +0000 |
| Message-ID | <56da4329$0$24032$e4fe514c@news.xs4all.nl> |
| In reply to | #45834 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >>I've been a professional c programmer for decades. >> >>I can't sympathize with the examples of >> signed int x; >> ... >> x-1>x >> .. >>and >> for (...... :dd[++k]) >>where the last access is outside the array bounds of dd. >> >>They are just bad code, that I would never write. >"I would never write this kind of bad code [so miscompiling it is fine >with me]" is a reaction some have when discussing this topic. I resent that you misrepresent my stand. " I would never write this kind of bad code, so I don't consider what happens to Anton Ertl a miscompilation, just something he had coming. " The word miscompiling in this context is the demagogic trick of the sort "Do you still beat your wife?" You seem to lack the basic understanding that Forth cells are present in C, they are just a union of a signed and an unsigned int. If you don't act accordingly, in my opinion you just get what you deserve. Elizabeth has expressed the opinion that writing a Forth compiler doesn't make one a Forth expert. Which is true of course. I would add the opinion that if you want a Forth compiler written in C you should hire a C-expert, not a Forth expert. >- 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]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-03-04 19:06 -0800 |
| Message-ID | <ce8ec9d2-2312-4664-9af5-f6507d762633@googlegroups.com> |
| In reply to | #45848 |
On Friday, March 4, 2016 at 7:35:02 PM UTC-7, Albert van der Horst wrote: > You seem to lack the basic understanding that Forth cells are > present in C, they are just a union of a signed and an unsigned > int. If you don't act accordingly, in my opinion you just get > what you deserve. That makes sense to me. > Elizabeth has expressed the opinion that writing a Forth > compiler doesn't make one a Forth expert. Which is true of course. > > I would add the opinion that if you want a Forth compiler written > in C you should hire a C-expert, not a Forth expert. It makes sense to write a Forth compiler in C if the goal is to use Forth as a scripting-language front-end for a C program --- the same goal that Lua was intended to satisfy --- actually, I think that Lua is a better choice for a scripting language than Forth, but it is realistic to use Forth (FICL had this goal). Unfortunately, this is almost never the goal that people have when they write a Forth compiler in C. These goals are much more common: 1.) They are C enthusiasts and they want to "prove" that C is the "god language" and that Forth is a toy language (Rod Pemberton). 2.) They are college professors and they know that they can't sell a class about Forth (the students will complain that the class has no real-world relevance and they won't sign up), so they describe the class as being about C and involving a fun but useless class project (Anton Ertl). 3.) They simply don't know assembly-language, and they don't want to learn (either because they are too dumb, or because they don't think that assembly-language has any real-world relevance and their goal is to get a job), so they use C which they do know in the hope that it will be fun and they will become better C programmers with a better chance of getting employed as C programmers after they graduate (most or all of Anton Ertl's students). By far, #1 above is the most common reason why people write a Forth compiler in C. When I was interviewing for jobs I would mention that I have Forth experience (the MFX development system at Testra). Almost invariably, the interviewer would state that he knows far more about Forth than I do because he is not just a mere Forth application-programmer like me, but is a Forth compiler-writer (woo hoo!). In the next breath he would state that Forth makes for a fun C project but Forth is utterly useless as an application-programming language (because his Forth written in C was slow as molasses and had no features whatsoever). Most if not all of the #3 group above will transition into the #1 group after they graduate. AFAIK, Anton Ertl is the only person in the #2 group --- he is the chair-person of the Forth-200x committee however, which gives him more prominence than he deserves.
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> |
|---|---|
| Date | 2016-03-05 20:32 -0500 |
| Message-ID | <20160305203221.0f07deff@_> |
| In reply to | #45849 |
On Fri, 4 Mar 2016 19:06:57 -0800 (PST) hughaguilar96@gmail.com wrote: > It makes sense to write a Forth compiler in C if the goal is to use > Forth as a scripting-language front-end for a C program --- the same > goal that Lua was intended to satisfy --- actually, I think that Lua > is a better choice for a scripting language than Forth, but it is > realistic to use Forth (FICL had this goal). > > Unfortunately, this is almost never the goal that people have when > they write a Forth compiler in C. These goals are much more common: ... > 1.) They are C enthusiasts and they want to "prove" that C is the > "god language" and that Forth is a toy language (Rod Pemberton). This is a distortion of what I said. C is the "god language". There is no need to prove it. All modern languages are derived from it and all languages have been implemented using it. I don't ever recall specifically using the words "toy language" to describe Forth, although I might have since Forth is so limited in many ways as compared to C. > 3.) They simply don't know assembly-language, Well, this definitely doesn't apply to me, as a I know a couple. So, how do you rationalize this statement with that in 1) ? > By far, #1 above is the most common reason why people write > a Forth compiler in C. I disagree. I think the most common reason why people write a Forth in C, be it a compiler or interpreter, is because C was very popular, widely implemented, and portable. Assembly isn't portable. Forth code is portable, but requires the availability of a Forth compiler or interpreter, which aren't widely available. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-06 11:28 +0000 |
| Message-ID | <2016Mar6.122816@mips.complang.tuwien.ac.at> |
| In reply to | #45848 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>You seem to lack the basic understanding that Forth cells are
>present in C, they are just a union of a signed and an unsigned
>int. If you don't act accordingly, in my opinion you just get
>what you deserve.
What do you mean with "act accordingly"?
If you mean implementing a Forth cell as
typedef union { long n; unsigned long u; } Cell;
how do you implement +, <, and u<? I am pretty sure that you will
produce non-standard C code.
>I would add the opinion that if you want a Forth compiler written
>in C you should hire a C-expert, not a Forth expert.
Well, as a self-proclaimed C expert and also Forth implementor, you
can certainly show us how to write a Forth system in standard C that
is on par with Gforth in performance; or actually, since you can
enable "optimizations", your Forth system should be able to beat
Gforth, no? To limit the scope of the exercise, let's just limit the
language to the words necessary to run the small integer benchmarks in
Gforth (siev.fs, bubble.fs, matrix.fs, fib.fs).
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-03-06 18:02 +0000 |
| Message-ID | <56dc70a7$0$24044$e4fe514c@news.xs4all.nl> |
| In reply to | #45888 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>You seem to lack the basic understanding that Forth cells are
>>present in C, they are just a union of a signed and an unsigned
>>int. If you don't act accordingly, in my opinion you just get
>>what you deserve.
>What do you mean with "act accordingly"?
>If you mean implementing a Forth cell as
>typedef union { long n; unsigned long u; } Cell;
>how do you implement +, <, and u<? I am pretty sure that you will
>produce non-standard C code.
+ Cell.u + Cell.u
You hope that it is two complement, i.e. the convention regards signed
and unsigned is the same then in Forth. If not you're in considerable
trouble.
< Cell.n<Cell.n
u< Cell.u<Cell.u
Any code involving situations where you have memory space that is now
considered containing an unsigned , later containing a signed is
not portable. That can't be helped! The best you can hope for is avoiding
ambiguous conditions. A Forth compiler in C can't be totally standard/portable.
That is the same discussion we have here with the likes of Hugh and Rod
regarding Forth implementations.
The code can be standard-compliant, and not be portable in the sense that after
checking the implementation defined differences, a Forth compiler doesn't
behave as intended.
>>I would add the opinion that if you want a Forth compiler written
>>in C you should hire a C-expert, not a Forth expert.
>Well, as a self-proclaimed C expert and also Forth implementor, you
>can certainly show us how to write a Forth system in standard C that
>is on par with Gforth in performance; or actually, since you can
>enable "optimizations", your Forth system should be able to beat
>Gforth, no? To limit the scope of the exercise, let's just limit the
>language to the words necessary to run the small integer benchmarks in
>Gforth (siev.fs, bubble.fs, matrix.fs, fib.fs).
As you could have guessed from my ciforth efforts, I'm of the opinion
that a Forth system is best written in assembler, so I'm not inclined
to put much effort in a c-based Forth.
Nevertheless in the right cooperative atmosphere I might offer my
services as a C-expert to clean up gforth's c-code.
For now it seems that nobody thinks there is anything to clean up.
>- anton
Groetjes Albert
P.S.
I applaud the gForth work, and I sympathize with your irritation with
the GNU/debian folks. A similar situation is with Debian, who no longer
distributes info files for legalistic reason.
--
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]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-06 23:55 +0000 |
| Message-ID | <nbig23$it8$1@dont-email.me> |
| In reply to | #45897 |
Am Sun, 06 Mar 2016 18:02:15 +0000 schrieb Albert van der Horst: > I applaud the gForth work, and I sympathize with your irritation with > the GNU/debian folks. A similar situation is with Debian, who no longer > distributes info files for legalistic reason. It looks like the Debian gforth port (and the missing documentation) is just a maintainer fuckup, and not a Debian fuckup as such. Debian allows GFDL documentation if there is no invariant section. Gforth's manual has no invariant section. -- 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]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-03-06 14:48 -0800 |
| Message-ID | <516ca7d2-4ee2-440c-a354-738a79da243b@googlegroups.com> |
| In reply to | #45888 |
On Sunday, March 6, 2016 at 4:52:28 AM UTC-7, Anton Ertl wrote: > Albert van der Horst <albert@spenarnc.xs4all.nl> writes: > >I would add the opinion that if you want a Forth compiler written > >in C you should hire a C-expert, not a Forth expert. > > Well, as a self-proclaimed C expert and also Forth implementor, you > can certainly show us how to write a Forth system in standard C that > is on par with Gforth in performance; or actually, since you can > enable "optimizations", your Forth system should be able to beat > Gforth, no? To limit the scope of the exercise, let's just limit the > language to the words necessary to run the small integer benchmarks in > Gforth (siev.fs, bubble.fs, matrix.fs, fib.fs). Nobody writes a Forth system in C because they care about speed. I said earlier that the only valid reason to write a Forth system in C is so you can have a scripting-language on top of a C program. Scripting languages don't have to be fast. Also, I said that Lua is a better choice than Forth anyway. I think that you made a deal with Elizabeth Rather. The deal was that she would appoint you to be the chair-person of the Forth-200x committee, but in exchange you had to agree to not compete with SwiftForth. You wrote gForth in C so that it would be slower than SwiftForth --- making a Forth system slower than SwiftForth takes some effort, because SwiftForth is abysmally slow --- but gForth is about 1/2 the speed of SwiftForth, so you fulfilled your part of the agreement. You don't care how slow gForth is because gForth is used only for teaching college students. They compare their gForth programs against their classmates' gForth programs, so it is a relative comparison but absolute speed is unimportant. If the students complain that gForth is slow as molasses and is unfit for commercial usage, then you tell them to buy SwiftForth which is faster --- this was the whole point of making gForth slow, so that SwiftForth would seem fast in comparison and Elizabeth Rather could make her sale, although SwiftForth is actually slow too --- it is a race to the bottom!
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-03-07 03:36 -0800 |
| Message-ID | <9cf5f43b-1de2-4127-b34f-8f3e5f3d4f96@googlegroups.com> |
| In reply to | #45903 |
On Sunday, March 6, 2016 at 4:48:11 PM UTC-6, hughag...@gmail.com wrote:
>
> Nobody writes a Forth system in C because they care about speed. [...]
>
> [...] You wrote gForth in C so that it would be slower than SwiftForth --- making a Forth system slower than SwiftForth takes some effort, because SwiftForth is abysmally slow --- but gForth is about 1/2 the speed of SwiftForth, so you fulfilled your part of the agreement.
>
$ make moves-bench
lina -c moves.frt
bash -c 'time ./moves'
204800
real 0m7.621s
user 0m7.620s
sys 0m0.001s
bash -c 'time sf moves.fs'
204800
real 0m8.237s
user 0m8.235s
sys 0m0.002s
bash -c 'time iforth moves.fs'
204800
real 0m0.878s
user 0m0.820s
sys 0m0.050s
bash -c 'time gforth moves.fs'
204800
real 0m0.676s
user 0m0.673s
sys 0m0.003s
These all just make a bunch of useless MOVEs between two buffers:
: moves ( -- )
buf1 1024 200 * bounds do
buf1 i over - buf2 swap move
#moves ++
loop #moves ? cr bye ;
-- Julian
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> |
|---|---|
| Date | 2016-03-07 19:19 -0500 |
| Message-ID | <20160307191917.0dd40763@_> |
| In reply to | #45888 |
On Sun, 06 Mar 2016 11:28:16 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Well, as a self-proclaimed C expert and also Forth implementor, you > can certainly show us how to write a Forth system in standard C that > is on par with Gforth in performance; or actually, since you can > enable "optimizations", your Forth system should be able to beat > Gforth, no? My Forth interpreter, the core coded in C, the rest currently in Forth, easily outperforms the Gforth interpreter, and I didn't do any optimization at all. It's actually interpreted, not C switch() based. Mine definitely wouldn't outperform the compiling Gforth, since it's an interpreter. I'm not sure about Albert's. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-12 17:40 +0000 |
| Message-ID | <2016Mar12.184039@mips.complang.tuwien.ac.at> |
| In reply to | #45925 |
Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> writes:
>On Sun, 06 Mar 2016 11:28:16 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> Well, as a self-proclaimed C expert and also Forth implementor, you
>> can certainly show us how to write a Forth system in standard C that
>> is on par with Gforth in performance; or actually, since you can
>> enable "optimizations", your Forth system should be able to beat
>> Gforth, no?
>
>My Forth interpreter, the core coded in C, the rest currently in Forth,
>easily outperforms the Gforth interpreter, and I didn't do any
>optimization at all. It's actually interpreted, not C switch()
>based. Mine definitely wouldn't outperform the compiling Gforth,
>since it's an interpreter.
Not really sure what you mean with "Gforth interpreter" vs. "compiling
Gforth", nor "actually interpreted". Anyway, where can I find this
Forth interpreter, so I can perform my own measurements and learn on
how to write C code in a way that makes all the
far-outside-the-C-standard stuff unnecessary that we introduced over
the years in the quest for performance.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-03-05 03:35 -0600 |
| Message-ID | <-_mdnWWb0cTTNUfLnZ2dnUU78WfNnZ2d@supernews.com> |
| In reply to | #45834 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Albert van der Horst <albert@spenarnc.xs4all.nl> writes: > >>I see the example of wheezy. "Half of the sources of packages >>exhibit this type of behaviour." I see it differently, >>the other half of the packages are truly professionally written. > > Not quite sure what you mean with "truly professionally written", > but if you mean the absence of undefined behaviour, no, Wang et > al.'s paper does not say that. I have to agree: in practice there can be very little doubt that professional programmers write C and C++ programs with undefined behaviour. In practice this tends to be difficult to determine statically, so something like GCC's undefined behavour sanitizer is required. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-05 13:37 +0000 |
| Message-ID | <nbenen$1gb$1@dont-email.me> |
| In reply to | #45850 |
Am Sat, 05 Mar 2016 03:35:10 -0600 schrieb Andrew Haley: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >> >>>I see the example of wheezy. "Half of the sources of packages exhibit >>>this type of behaviour." I see it differently, >>>the other half of the packages are truly professionally written. >> >> Not quite sure what you mean with "truly professionally written", >> but if you mean the absence of undefined behaviour, no, Wang et al.'s >> paper does not say that. > > I have to agree: in practice there can be very little doubt that > professional programmers write C and C++ programs with undefined > behaviour. In practice this tends to be difficult to determine > statically, so something like GCC's undefined behavour sanitizer is > required. No, a change of mentality is required that changes UB into IB as appropriate. You have to think. Hopefully, Google will implement thinking through deep learning in the near future, then just load the thinking module, and think. Example: Integer overflow is no UB on any platforms GCC supports. It's wraparound 2th complement, therefore it is perfectly defined. Just make sure that it's -fwrapv by default and -ftrapv on request (and maybe add - fsatv for DSPs and corresponding type attributes to allow the user to specify a mix of wrapping, trapping, and saturated integers), and remove all the dead code if it isn't. Or NULL pointer access: It is an access to the virtual address 0. If it is mapped, this will not cause an exception, so any code afterwards matters. There are around 200 UBs in the C standard, just go through the list, and check what happens in reality. Understanding an ISA and machine is something I expect as competence from a compiler writer, so just do it. The sanitizer causes significant slowdown by inserting a lot of code, even though the UB is deterministically handled by the platform. Just define it, for god's sake! In case of doubt what a possible reasonable definition would be, just look into the Java standard. The C standard allows compiler writers to define UB in their implementation. This is fully compliant with the C standard, and their actual intention (at least of the first ANSI C). -- 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]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-03-05 15:42 -0600 |
| Message-ID | <bcidneoCodhFz0bLnZ2dnUU78NmdnZ2d@supernews.com> |
| In reply to | #45854 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Am Sat, 05 Mar 2016 03:35:10 -0600 schrieb Andrew Haley: > >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >>> >>>>I see the example of wheezy. "Half of the sources of packages exhibit >>>>this type of behaviour." I see it differently, >>>>the other half of the packages are truly professionally written. >>> >>> Not quite sure what you mean with "truly professionally written", >>> but if you mean the absence of undefined behaviour, no, Wang et al.'s >>> paper does not say that. >> >> I have to agree: in practice there can be very little doubt that >> professional programmers write C and C++ programs with undefined >> behaviour. In practice this tends to be difficult to determine >> statically, so something like GCC's undefined behavour sanitizer is >> required. > > No, a change of mentality is required that changes UB into IB as > appropriate. That's a different matter altogether. The question was about whether professional programmers write programs with undefined behaviour. > There are around 200 UBs in the C standard, just go through the > list, and check what happens in reality. There are some in Forth too. There are fewer, sure, but Forth is a simpler language. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web