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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-12 16:02 +0000 |
| Message-ID | <2016Mar12.170252@mips.complang.tuwien.ac.at> |
| In reply to | #45957 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>Relational comparison of pointers: The result is either 0 or 1; there
>>are people who dream up hardware that produes an exception for
>>comparison of pointers to different segments, but the dreams are based
>>on such machines behaving funny for other cases, not on knowledge for
>>this case, and no such funny machines have actually been named.
>>Anyway, even if the result was an exception, it's totally in the hands
>>of the implementation how to react to that.
>
>I don't find it particular hard to find an example. If I've an Intel
>machine and I'm running a debugger at the highest priority, and couple
>to a segment via e.g. the GS segment register for the program to
>be debugged. Comparing pointers, one located in the debugger, on
>in the debuggee makes very little sense and could justifiably
>result in an exception.
As I said, dreaming up something is no problem for anybody so inclined
(and you are more so inclined than most). The question is if it
happens in reality. And "cmp reg1, reg2" (the instruction for
comparing two addresses on IA-32 and AMD64, and this instruction is
used by C compilers in the general case) does not generate an
exception, much as you might wish for it.
- 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-10 08:22 -0600 |
| Message-ID | <kOqdnSfcY8zeHnzLnZ2dnUU7-f_NnZ2d@supernews.com> |
| In reply to | #45956 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> >>> Your point was that an implementer can always be a dick and say "I'm >>> not going to specify that". The language specification however >>> could restrict IB behavior to a certain class of defined behavior. >> >>In the general case that's not possible without a lot of runtime >>checking. > > But in most cases it is possible without any run-time checking. In > particular, for all the cases mentioned in my paper it is: > > Integer overflow: Either the result is in the range of the result > type, or there is an exception (and it's totally in the hands of the > implementation how to react to that). > > Shifting by the number of bits in the type: The result is in the range > of the result type. Indeed. As discussed, two's complement with wraparound makes perfect sense for Forth standardization. > Out-of-bounds array access: Either the result is in the range of the > result type, or there is an exception (and it's totally in the hands > of the implementation how to react to that). UB, then. You can't get away from that one. > In kernel mode one may also get some side effect if the read is from > memory-mapped I/O, but normal user-mode programs cannot do that. > > Relational comparison of pointers: The result is either 0 or 1; there > are people who dream up hardware that produes an exception for > comparison of pointers to different segments, but the dreams are based > on such machines behaving funny for other cases, not on knowledge for > this case, and no such funny machines have actually been named. > Anyway, even if the result was an exception, it's totally in the hands > of the implementation how to react to that. > > The only thing that can do pretty wild things in user space are wild > stores and wild jumps. Or anything which might result in such; there are a few of these. I'm not sure that "user space" makes any sense in the context of a Forth system. Forth is often natively hosted, and the standard has no concept of user and kernel space. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-12 15:49 +0000 |
| Message-ID | <2016Mar12.164948@mips.complang.tuwien.ac.at> |
| In reply to | #45961 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Out-of-bounds array access: Either the result is in the range of the
>> result type, or there is an exception (and it's totally in the hands
>> of the implementation how to react to that).
>
>UB, then. You can't get away from that one.
Up to now that's just the same options that I listed for integer
overflow. You are very eager to undefine behaviour.
>> In kernel mode one may also get some side effect if the read is from
>> memory-mapped I/O, but normal user-mode programs cannot do that.
...
>I'm not sure that "user space" makes any sense in the context of a
>Forth system.
Certainly.
>Forth is often natively hosted, and the standard has no
>concept of user and kernel space.
Does vfxlin (and programs running on it) run in kernel
mode? No, it doesn't.
Does SwiftForth (and programs running on it)
run in kernel mode? No.
Does Mecrisp (and its programs) run in kernel mode? Yes, but if there
is no user mode, one usually does not call it kernel mode.
For SwiftX, likewise.
- 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-12 13:35 -0600 |
| Message-ID | <OZ-dnd6Jv-4M8nnLnZ2dnUU7-KNi4p2d@supernews.com> |
| In reply to | #45998 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Out-of-bounds array access: Either the result is in the range of the >>> result type, or there is an exception (and it's totally in the hands >>> of the implementation how to react to that). >> >>UB, then. You can't get away from that one. > > Up to now that's just the same options that I listed for integer > overflow. You are very eager to undefine behaviour. What do you mean? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-10 21:58 +0000 |
| Message-ID | <nbsqmo$jiu$1@dont-email.me> |
| In reply to | #45956 |
Am Thu, 10 Mar 2016 11:39:04 +0000 schrieb Anton Ertl: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> >>> Your point was that an implementer can always be a dick and say "I'm >>> not going to specify that". The language specification however could >>> restrict IB behavior to a certain class of defined behavior. >> >>In the general case that's not possible without a lot of runtime >>checking. > > But in most cases it is possible without any run-time checking. In > particular, for all the cases mentioned in my paper it is: > > Integer overflow: Either the result is in the range of the result type, > or there is an exception (and it's totally in the hands of the > implementation how to react to that). Actually, more precisely, all hardware I know has one of the following three behavoirs on integer overflow: a) result is wraparound (mod 2^n for two's complement, mod 2^n-1 for one's complement, but that has died out) b) result is saturated (DSPs) c) delivers an exception (-ftrapv). > Shifting by the number of bits in the type: The result is in the range > of the result type. Actually, there are only two possible results: 0 or the input; -1 as possible third result for signed right shift of negative numbers. > Out-of-bounds array access: Either the result is in the range of the > result type, or there is an exception (and it's totally in the hands of > the implementation how to react to that). In kernel mode one may also > get some side effect if the read is from memory-mapped I/O, but normal > user-mode programs cannot do that. Yes, but the kernel case should not be forgotten, like with page 0 (page 0 is not mapped in a user program, but for kernels, the physical memory may be mapped starting with address 0). > Relational comparison of pointers: The result is either 0 or 1; there > are people who dream up hardware that produes an exception for > comparison of pointers to different segments, but the dreams are based > on such machines behaving funny for other cases, not on knowledge for > this case, and no such funny machines have actually been named. Anyway, > even if the result was an exception, it's totally in the hands of the > implementation how to react to that. > > The only thing that can do pretty wild things in user space are wild > stores and wild jumps. Indeed, and even then: The wild jump just executes the machine code at the jumped to location. Read the processor manual for details what happens. I would guess that a goto * not to a label in GCC is UB, so Gforth -- dynamic is doing an IB for every single goto *. Ok, it's actually doing that for the bytes in some other memory location copied from the label address, not the original goto *, but that's for sure double-UB ;-). I would expect that the bytes between two labels in a C program corresponds to the machine code translated from the C statements between those two labels. For the Gforth relocatibility comparison, we need reproducible builds, i.e. two builds of the same source (which just differ by the inserted padding) create the same machine code. This is something I would not actually enforce, but reproducible builds are something people want to have to check whether they can trust some distributed binary. If it is possible to reproduce the build from the same source, a trust relationship between different binary repositories can be established. -- 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-11 06:11 -0600 |
| Message-ID | <XtqdnVbEKIJJKH_LnZ2dnUU7-RPNnZ2d@supernews.com> |
| In reply to | #45966 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Am Thu, 10 Mar 2016 11:39:04 +0000 schrieb Anton Ertl: > >> >> The only thing that can do pretty wild things in user space are wild >> stores and wild jumps. > > Indeed, and even then: The wild jump just executes the machine code at > the jumped to location. Read the processor manual for details what > happens. You might be surprised: according to ARM, modifying an instruction while some other tread is executing it can "lead to the resulting instruction performing any behavior that can be achieved by executing any sequence of instructions that can be executed from the same Exception level..." That's about as UB as it gets. BTW, that comment I made about a wild jump bricking a system wasn't just speculation: I have encountered that in the Real World. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-12 00:05 +0000 |
| Message-ID | <nbvmfq$lr6$1@dont-email.me> |
| In reply to | #45978 |
Am Fri, 11 Mar 2016 06:11:00 -0600 schrieb Andrew Haley: > You might be surprised: according to ARM, modifying an instruction while > some other tread is executing it can "lead to the resulting instruction > performing any behavior that can be achieved by executing any sequence > of instructions that can be executed from the same Exception level..." > That's about as UB as it gets. Incoherent caches are a bad idea. This is a quality of implementation issue, and if ARM wants to go into the high reliable server space, they must stop that. I think it's even worse than that: If you have dynamic code generation as in Gforth, or a native code Forth like VFX (or any other JIT), and you generate code while you run a thread, and that thread already executed the previously compiled code at the beginning of a cache line, flushing the cache line in the compiler thread after adding more code to that cache line will not flush the cache line in the other thread, and if you want to execute the new word there, kaboom. Therefore, to all computer architects: Make all your caches coherent. Use a clear and obvious memory model, and not some fuckup, because you are lazy. If you have problems understanding that, forget about the server market. > BTW, that comment I made about a wild jump bricking a system wasn't just > speculation: I have encountered that in the Real World. But that just jumped to a sequence of instructions that bricked the system. It's not the wild jump as such that is bricking the system, it's the executed code at that location. -- 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-12 04:23 -0600 |
| Message-ID | <qq6dnb61R6u1c37LnZ2dnUU7-IXNnZ2d@supernews.com> |
| In reply to | #45979 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Am Fri, 11 Mar 2016 06:11:00 -0600 schrieb Andrew Haley: >> You might be surprised: according to ARM, modifying an instruction while >> some other tread is executing it can "lead to the resulting instruction >> performing any behavior that can be achieved by executing any sequence >> of instructions that can be executed from the same Exception level..." >> That's about as UB as it gets. > > Incoherent caches are a bad idea. This is a quality of > implementation issue, and if ARM wants to go into the high reliable > server space, they must stop that. Well, perhaps, but your claim that undefined behaviour is in some way constrained has been proved to be false, at least on ARM systems. Which are very common. QED. WRT caches, I understand your point, but automagically synchronizing memory across many cores is expensive in power and requires a lot of transistors. Given that the future seems to be large-scale shared-memory systems with many cores, there is a severe scalability problem if you insist on a total store order across the system. > I think it's even worse than that: If you have dynamic code > generation as in Gforth, or a native code Forth like VFX (or any > other JIT), and you generate code while you run a thread, and that > thread already executed the previously compiled code at the > beginning of a cache line, flushing the cache line in the compiler > thread after adding more code to that cache line will not flush the > cache line in the other thread, and if you want to execute the new > word there, kaboom. I do this every day. When you publish a newly-compiled slab of code you have to make sure that the target thread executes an instruction synchronization barrier. In practice it's really not that difficult to handle given a little discipline. The other thread is either going to access the newly-compiled code via an execution vector or a dictionary lookup. And in theory it's possible for an OS kernel to use an inter-processor interrupt to do an ISB on all cores, but I haven't tried that. >> BTW, that comment I made about a wild jump bricking a system wasn't just >> speculation: I have encountered that in the Real World. > > But that just jumped to a sequence of instructions that bricked the > system. It's not the wild jump as such that is bricking the system, > it's the executed code at that location. Erm, yes, obiously, but I don't know why you think this matters. It makes no difference to the deadness of the system. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-12 12:05 +0000 |
| Message-ID | <2016Mar12.130518@mips.complang.tuwien.ac.at> |
| In reply to | #45982 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Am Fri, 11 Mar 2016 06:11:00 -0600 schrieb Andrew Haley:
>>> You might be surprised: according to ARM, modifying an instruction while
>>> some other tread is executing it can "lead to the resulting instruction
>>> performing any behavior that can be achieved by executing any sequence
>>> of instructions that can be executed from the same Exception level..."
>>> That's about as UB as it gets.
It's far more defined than undefined behaviour in C. No nasal demons.
No time travel. Not even things that are possible on the machine at a
different exception level.
>> Incoherent caches are a bad idea. This is a quality of
>> implementation issue, and if ARM wants to go into the high reliable
>> server space, they must stop that.
I don't think that the author of that specification was thinking about
incoherent caches. With an incoherent cache with word-wide access,
you get the old content or the new one, not something else. He may
have been thinking about narrow memory systems where, say, one CPU
changes the instruction a bit at a time while the other is fetching
the instruction; then you get some mixture of the two instructions; no
idea why the author specified a sequence. There is no need for caches
is this scenario.
>Well, perhaps, but your claim that undefined behaviour is in some way
>constrained has been proved to be false, at least on ARM systems.
Not in the least. It only proves that the author of the specification
followed the bad example of some programming language specifications
(i.e., fail to specify in more detail what can happen) instead of the
good example of most architecture specifications. One more reason to
avoid ARM. Maybe the low quality of their specifications are the
reason why they don't publish them.
To prove that undefined beaviour is really as unconstrained as
specified, you would have to present an existing ARM implementation
that actually exhibits this behaviour.
- 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-12 08:36 -0600 |
| Message-ID | <HI-dnbsDL_QftHnLnZ2dnUU7-RHNnZ2d@supernews.com> |
| In reply to | #45983 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> Am Fri, 11 Mar 2016 06:11:00 -0600 schrieb Andrew Haley: >>>> You might be surprised: according to ARM, modifying an instruction while >>>> some other tread is executing it can "lead to the resulting instruction >>>> performing any behavior that can be achieved by executing any sequence >>>> of instructions that can be executed from the same Exception level..." >>>> That's about as UB as it gets. > > It's far more defined than undefined behaviour in C. No nasal demons. > No time travel. Not even things that are possible on the machine at a > different exception level. Heh, true enough. Shame about the time travel. :-) >>Well, perhaps, but your claim that undefined behaviour is in some way >>constrained has been proved to be false, at least on ARM systems. > > Not in the least. I think it has: it's as unconstrained as is possible in any practical machine architecture. I suppose they might have said the machine may catch fire, but that would surprising in an architecture specification, if not so surprising in a physical chip. > To prove that undefined beaviour is really as unconstrained as > specified, you would have to present an existing ARM implementation > that actually exhibits this behaviour. No I don't: Bernd spoke explicitly about "read the manual" so that's what I did. Of course every ARM implementation actually exhibits this behaviour. It must be so, because the possible behaviour is anything possible at the current exception level, and they all do something. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-12 16:57 +0000 |
| Message-ID | <2016Mar12.175705@mips.complang.tuwien.ac.at> |
| In reply to | #45996 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Well, perhaps, but your claim that undefined behaviour is in some way
>>>constrained has been proved to be false, at least on ARM systems.
...
>> To prove that undefined beaviour is really as unconstrained as
>> specified, you would have to present an existing ARM implementation
>> that actually exhibits this behaviour.
>
>No I don't: Bernd spoke explicitly about "read the manual" so that's
>what I did.
And you claimed that it has been "proved to be false, at least on ARM
*systems*." (emphasis mine). If you make a claim about systems,
please present these systems.
>Of course every ARM implementation actually exhibits this behaviour.
>It must be so, because the possible behaviour is anything possible at
>the current exception level, and they all do something.
Sure, but your claim was not that they do something (which is what I
claim, too), but that what they do is not constrained; i.e., there
should be at least one implementation whose behaviour cannot be
described in a more constrained way.
- 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-12 13:44 -0600 |
| Message-ID | <1tmdnSTi3Y8z7HnLnZ2dnUU7-RfNnZ2d@supernews.com> |
| In reply to | #46002 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Well, perhaps, but your claim that undefined behaviour is in some way >>>>constrained has been proved to be false, at least on ARM systems. > ... >>> To prove that undefined beaviour is really as unconstrained as >>> specified, you would have to present an existing ARM implementation >>> that actually exhibits this behaviour. >> >>No I don't: Bernd spoke explicitly about "read the manual" so that's >>what I did. > > And you claimed that it has been "proved to be false, at least on ARM > *systems*." (emphasis mine). If you make a claim about systems, > please present these systems. Oh, I now see what you're getting at. By "systems" you mean real physical implementations of the specification, not some abstraction. OK, I clumsily worded my reply: I was referring not to real implementations but to the manual, which was what Bernd mentioned. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-12 14:29 +0000 |
| Message-ID | <2016Mar12.152958@mips.complang.tuwien.ac.at> |
| In reply to | #45966 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Am Thu, 10 Mar 2016 11:39:04 +0000 schrieb Anton Ertl:
>
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>>>
>>>> Your point was that an implementer can always be a dick and say "I'm
>>>> not going to specify that". The language specification however could
>>>> restrict IB behavior to a certain class of defined behavior.
>>>
>>>In the general case that's not possible without a lot of runtime
>>>checking.
>>
>> But in most cases it is possible without any run-time checking. In
>> particular, for all the cases mentioned in my paper it is:
>>
>> Integer overflow: Either the result is in the range of the result type,
>> or there is an exception (and it's totally in the hands of the
>> implementation how to react to that).
>
>Actually, more precisely, all hardware I know has one of the following
>three behavoirs on integer overflow:
>
>a) result is wraparound (mod 2^n for two's complement, mod 2^n-1 for
>one's complement, but that has died out)
>b) result is saturated (DSPs)
>c) delivers an exception (-ftrapv).
Sure, one can make it more precise. My point was that no wild things
happen. The instruction either delivers a result and execution
continues, or it causes an exception (and implementations define how
they react to that).
So it's not like an out-of-bounds store that overwrites some code
address or somesuch that eventually leads to arbitrary execution,
which can do anything a program can do in that environment. In the
latter case, sure, one can imagine that a program involved in
launching ICBMs might start World War III if worst comes to worst. So
the phrase that undefined behaviour may result in starting WW3 is
based on an unlikely, but possible chain of events.
My point was that many things that are undefined behaviour in C have
more limited consequences in the first order than wild stores or wild
jumps (of course, it is possible that an unexpected result or
exception can have very bad consequences further down the road, but
that can also happen without undefined behaviour, as the Ariane 5
incident demonstrates).
>> Shifting by the number of bits in the type: The result is in the range
>> of the result type.
>
>Actually, there are only two possible results: 0 or the input;
That's actually needed for the example in my paper to be correct, but
not necessary for the point I am trying to make above.
>> Out-of-bounds array access: Either the result is in the range of the
>> result type, or there is an exception (and it's totally in the hands of
>> the implementation how to react to that). In kernel mode one may also
>> get some side effect if the read is from memory-mapped I/O, but normal
>> user-mode programs cannot do that.
>
>Yes, but the kernel case should not be forgotten, like with page 0 (page
>0 is not mapped in a user program, but for kernels, the physical memory
>may be mapped starting with address 0).
These are two sides of the same medal. The C standard does not define
accesses to 0, because these produce exceptions in user mode, and it
does not define out-of-bounds reads, because they can produce
exceptions, and they can also activate memory-mapped I/O in kernel
mode. The gcc maintainers see that as a license to miscompile
programs that do such things, in whatever mode they are run.
>I would guess that a goto * not to a label in GCC is UB, so Gforth --
>dynamic is doing an IB for every single goto *.
Not sure I follow that, but indeed, in llvm-gcc the labels were not
machine code addresses, but some integers; I did not try what happens
when you give it arbitrary integers. The resulting "labels" failed
the sanity check for gforth --dynamic, so gforth ran without dynamic
code generation on llvm-gcc (and there must have been more; it was
about 6 times slower than gcc).
>I would expect that the bytes between two labels in a C program
>corresponds to the machine code translated from the C statements between
>those two labels. For the Gforth relocatibility comparison, we need
>reproducible builds, i.e. two builds of the same source (which just
>differ by the inserted padding) create the same machine code. This is
>something I would not actually enforce, but reproducible builds are
>something people want to have to check whether they can trust some
>distributed binary. If it is possible to reproduce the build from the
>same source, a trust relationship between different binary repositories
>can be established.
Certainly more trust than if you cannot reproduce the build, but note
that "Reflections on Trusting Trust" allows a backdoor even with a
reproducable build. You need to introduce a compiler that the
attacker did not take into consideration in order to get around that.
But anyway, yes, for a nasal-demon fan the Gforth engine is something
they love to miscompile, for many reasons.
- 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-03-11 15:02 -1000 |
| Message-ID | <LaidnSLNfNUK937LnZ2dnUU7-VfNnZ2d@supernews.com> |
| In reply to | #45948 |
On 3/8/16 11:14 PM, Andrew Haley wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> Am Tue, 08 Mar 2016 05:17:08 -0600 schrieb Andrew Haley: >> >> If I, as Forth programmer, overwrite the code field of a word, the result >> is probably a crash. Or a clever redefinition of that word. A standard >> may not able to specify when it's a redefinition and when it's going to >> crash, but an implementation can. > > Exactly so: this simply isn't something that you can do in a language > specification. > >>> A smaller effect might be to cause some code not to be executed >>> because of a wild jump, so you don't even notice it. So, no, I do >>> not accept such a distinction. I think it's a distinction without >>> a difference, because no standard Forth program can tell the >>> difference between unspecified behaviour possibly leading to a >>> crash and undefined behaviour. >> >> Forth programmers usually just try to figure it out. > > Well, yes. But this has nothing to do with the language specification, > but what a particular implementation does. There's nothing wrong with > that. > >> And to some extent, Forth programs can do that, as well, in contrast >> to C programs, which can't run parts of themselves during >> compilation. > > Indeed so. > >>>> I however agree that we should reduce the number of ambiguous >>>> conditions, and make it more obvious what can happen. E.g. a >>>> number of ambiguous conditions could be make "throw an >>>> implementation defined error code". Still implementation defined, >>>> but it has to be a THROW. >>> >>> That sounds like a good idea, but does it require exceptions in CORE? >> >> We could formulate it "when the exception wordset is present, THROW >> implementation defined code, otherwise ABORT or ABORT" with an >> implementation defined error message". > > That sounds very sensible. Careful, watch for unintended consequences. Some things, such as using compiler directives interpretively, are supported on some systems. You don't want to prohibit that (I hope) by requiring an abort. Also, remember that "implementation defined" does require a standard system to *document* what the consequence is, so it shouldn't be all that "unknown". In geneeral, though, specifying an abort when it's a detectable problem and that's really the only thing that makes sense, is a good idea. Cheers. Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-12 16:20 +0000 |
| Message-ID | <2016Mar12.172059@mips.complang.tuwien.ac.at> |
| In reply to | #45938 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Oh dear. Well, a crash can do anything: lose the vehicle, cause the
>patient to die, etc.
No. When I am making a SPEC run on my server, the out-of-bounds read
on h264 cannot lose a vehicle or cause a patient to die.
>So, no, I do not accept such a distinction. I think it's a
>distinction without a difference, because no standard Forth program
>can tell the difference between unspecified behaviour possibly leading
>to a crash and undefined behaviour.
Is this some kind of halting problem or Turing test claim?
Who cares if a standard Forth program can do it? I certainly can tell
the difference between the h264 program running on my server 1) being
caught in an endless loop 2) working as intended and 3) crashing with
a SIGSEGV, because the out-of-bounds access actually was to some
unmapped memory. 2) and 3) are the results expected in that
environment for this kind of programming error, 1) is only possible
with undefined behaviour in collaboration with the nasal-demon
interpretation.
>> I however agree that we should reduce the number of ambiguous conditions,
>> and make it more obvious what can happen. E.g. a number of ambiguous
>> conditions could be make "throw an implementation defined error code".
>> Still implementation defined, but it has to be a THROW.
>
>That sounds like a good idea, but does it require exceptions in CORE?
Yes, it would, but that may be a good idea anyway. Is there any
standard Forth system that supports CORE and does not support
exceptions?
Advantage of putting exceptions in CORE: We could avoid introducing
more ior-returning words (which always result in phrases such as
ALLOCATE THROW) in the future.
- 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-12 13:53 -0600 |
| Message-ID | <4vydnZIwUu4x7nnLnZ2dnUU7-IHNnZ2d@supernews.com> |
| In reply to | #46000 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>So, no, I do not accept such a distinction. I think it's a >>distinction without a difference, because no standard Forth program >>can tell the difference between unspecified behaviour possibly leading >>to a crash and undefined behaviour. > > Is this some kind of halting problem or Turing test claim? > > Who cares if a standard Forth program can do it? I certainly can > tell the difference between the h264 program running on my server 1) > being caught in an endless loop 2) working as intended and 3) > crashing with a SIGSEGV, because the out-of-bounds access actually > was to some unmapped memory. 2) and 3) are the results expected in > that environment for this kind of programming error, 1) is only > possible with undefined behaviour in collaboration with the > nasal-demon interpretation. OK, but what is the relevance of this? My contention is that there is no meaningful difference between Forth's unspecified behaviour and undefined behaviour in the C sense. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-06 13:02 +0000 |
| Message-ID | <2016Mar6.140248@mips.complang.tuwien.ac.at> |
| In reply to | #45867 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Actually, we have quite some ambiguous conditions in Forth 2012, where
>the standard does not specify what happens (if they are all listed in the
>summary about ambiguous conditions, there are 38; that however counts all
>the undefined interpretation semantics as one; while an implementer can
>choose individually for every word with undefined interpretation
>semantics what it does during interpretation). Yes, Forth is a simpler
>language, so we have less ambiguous conditions than C has UBs.
Or maybe we were just less thorough. Now and then there is a question
about something where the standard does not define the behaviour, but
does not explicitly make it into an ambiguous condition.
>However, an ambiguous condition is not an UB, but an IB, i.e. though the
>system implementer is free to do whatever he likes, he has to document
>the behavior. From a user's point of view, a documented behavior is a
>feature (e.g. "a buffer overflow overwrites the locations at higher
>memory addresses after the end of the buffer up to the length of the
>requested write and throws -9 if this proceeds far enough to reach
>unmapped memory" or "a division by zero throws -10"), so the user of a
>particular system can rely on the documented behavior, and the system
>implementer will only change the behavior if that is perceived as
>improvement by implementer *and* users.
My take on the documentation requirements for ambiguous conditions is
different: I think they offer too little benefit for the users to be
worth the cost. How often do you look up this part of the
documentation of a Forth system?
I also don't care much about the difference between undefined and
implementation-defined behaviour in C, although C language lawyers
make a big issue out of that. So one is documented and the other
isn't. Documentation can change between releases, so this does not
buy me anything. Either the maintainers of a C compiler feel obliged
to provide a compiler that compiles existing tested, working and
maintainable programs as intended with the next version of the
compiler, or they don't. In case of GCC and Clang, they don't; though
for certain benchmarks, they do, even for undefined behaviour.
>There are some ambiguous conditions we are about to remove, e.g. with the
>two's complement RfD. Or the separate FP stack, where we made clear that
>a separate FP stack is the preferred way to implement FP.
The separate FP stack is standard in Forth-2012. I don't think there
was an ambiguous condition associated with this stuff, even though, say,
1e 1 f.
is not a Forth-94 program (it is Forth-2012).
>Work for a standard committee to convert UB to IB: Change a few lines and
>search&replace UB by IB throughout the document. Work for the
>implementer: Document every fucking IB, thus making it a feature, and
>then keep it stable when the feature is reasonable.
I don't think we need all this documentation. The compiler
maintainers would just document all the new implementation-defined
behaviour as undefined behaviour; but even if that is not allowed, the
documentation itself does not really provide a significant benefit.
I think that what we need is a tighter definition of what an
implementation can do on undefined behaviour. I.e., no nasal demons.
Is it possible? I think so: Supposedly the way to overwrite a buffer
such that the overwriting is not "optimized" away is to use volatile
or memset_s(). So apparently they phrased these C language features
in a way that the evil combination of undefined behaviour and the
as-if rule cannot strike. Just apply that kind of magic to the
definition of undefined behaviour, and "optimization" will become
non-standard.
But I will leave it to someone else to try this approach. As I wrote,
I find the fault in the C compiler maintainers, because out of the
many implementations allowed by the standard, they strive to go for
one that excludes lots (according to DJ Bernstein, 100%) of existing
working programs.
Sure, one could tighten the standard to disallow such implementations,
but the standard cannot fix the attitude of the compiler maintainers,
and with the current attitude, they will find loopholes in the C
standard to pervert it; ok, close some more holes in the next
revision, etc., and when you are done, it's 30 years later, and
standard C has become as relevant as standard Pascal is now.
- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-06 11:52 +0000 |
| Message-ID | <2016Mar6.125249@mips.complang.tuwien.ac.at> |
| In reply to | #45850 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>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.
But that approach has two problems:
1) These dynamic checkers do not recognize all undefined behaviours
occuring in a run.
2) Even if they did recognize all of them, they recognize only those
behaviours occuring in the specific run.
But even if we could find all undefined behaviours, what's the point?
Lots of effort spent on writing the "sanitizers", more effort spent on
running them, and even more for removing the undefined behaviours
(possibly resulting in bugs or a performance degradation). And the
benefit is? Is it worth the costs? I doubt it.
- 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-06 12:42 -0600 |
| Message-ID | <aI-dnQ_K7tee50HLnZ2dnUU78TWdnZ2d@supernews.com> |
| In reply to | #45891 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >>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. > > But that approach has two problems: > > 1) These dynamic checkers do not recognize all undefined behaviours > occuring in a run. I agree. > 2) Even if they did recognize all of them, they recognize only those > behaviours occuring in the specific run. I agree with that too. Detecting all kinds of UB is probably impossible for the same reason that it's impossible to detect that a program terminates. > But even if we could find all undefined behaviours, what's the > point? It's useful today, with the compilers and the programs we have. It can help to prevent nasty surprises. I claim no more than that. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-03-06 13:12 -0600 |
| Message-ID | <NuWdnV2jcZCoHEHLnZ2dnUU78LfNnZ2d@supernews.com> |
| In reply to | #45898 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> >>>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. >> >> But that approach has two problems: >> >> 1) These dynamic checkers do not recognize all undefined behaviours >> occuring in a run. > > I agree. > >> 2) Even if they did recognize all of them, they recognize only those >> behaviours occuring in the specific run. > > I agree with that too. Detecting all kinds of UB is probably > impossible for the same reason that it's impossible to detect that a > program terminates. Argh! Of course it's possible to detect that a program terminates! I meant to say that it's impossible write an analyzer which can determine whether an arbitrary program written in C will perform some kind of UB with some input. I suspect that it's possible in principle to detect all kinds of UB at runtime, though. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web