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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-06 00:50 +0000 |
| Message-ID | <nbfutd$i9m$2@dont-email.me> |
| In reply to | #45861 |
Am Sat, 05 Mar 2016 15:42:48 -0600 schrieb Andrew Haley: > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> 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. 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. 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. 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. This improves portability; while the conversion of UB to IB does not promote portability (the programs are still non-portable), but forces the implementer to document his choices, and by doing so, they become features of his implementation. I also think it's a good idea to point out which ambiguous condition is related to exotic platforms, and therefore, there's a default choice. If the IEEE FP RfD gets on the table again; I'd suppose that IEEE conformance for the FP would become such a thing: There is still place for non IEEE-conforming FP and Forth, but a program can assume that anything else is exotic. What we need to be concerned about is deviation from the standard for non- exotic implementations, like the restrictions that come from compile-to- flash Forth systems. There are things like CREATE, which we do specify in a way that makes it, let's say "tricky", to implement right, and such a tricky implementation is not in the spirit of Forth. 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. The wording in the C standard allows that implementer treat UB as IB, as one possible action on UBs for implementers is to document the behavior. I would remove the other possible actions, or at least make clear that the other possible options are not first-class ones. -- 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 | Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> |
|---|---|
| Date | 2016-03-05 20:33 -0500 |
| Message-ID | <20160305203316.0ac4965d@_> |
| In reply to | #45867 |
On Sun, 6 Mar 2016 00:50:53 -0000 (UTC) Bernd Paysan <bernd.paysan@gmx.de> wrote: > Yes, Forth is a simpler language, so we have less > ambiguous conditions than C has UBs. That makes no sense. A Forth word will pull whatever data it needs from the stack without being able to check that the data is correct before use of said data. There is no type checking in Forth. Therefore, every Forth word which removes data from the data stack potentially has UB. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-06 02:01 +0000 |
| Message-ID | <nbg315$i9m$5@dont-email.me> |
| In reply to | #45872 |
Am Sat, 05 Mar 2016 20:33:16 -0500 schrieb Rod Pemberton: > On Sun, 6 Mar 2016 00:50:53 -0000 (UTC) > Bernd Paysan <bernd.paysan@gmx.de> wrote: > >> Yes, Forth is a simpler language, so we have less ambiguous conditions >> than C has UBs. > > That makes no sense. > > A Forth word will pull whatever data it needs from the stack without > being able to check that the data is correct before use of said data. > There is no type checking in Forth. Therefore, every Forth word which > removes data from the data stack potentially has UB. That there is no type-checking does not make the behavior undefined. Example: In C, there is a UB for pointer comparison. In Forth, pointers are just cell-sized data, and you can compare any two pointers, and the result always only depends on their location in the flat address space Forth has; you don't use a special pointer-comparison instruction, but the one for unsigned integers, as all addresses are subsets of the data type u. You can compare a pointer with a char in Forth (this is even formally ok with the type system from section 3.1.1), which does not make sense, but the result is well-defined, because the comparison operator used is just an integer comparison. -- 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 | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-03-06 11:57 +0000 |
| Message-ID | <56dc1b43$0$24116$e4fe514c@news.xs4all.nl> |
| In reply to | #45877 |
Bernd Paysan <bernd.paysan@gmx.de> writes: <SNIP> >That there is no type-checking does not make the behavior undefined. >Example: In C, there is a UB for pointer comparison. In Forth, pointers >are just cell-sized data, and you can compare any two pointers, and the >result always only depends on their location in the flat address space >Forth has; you don't use a special pointer-comparison instruction, but >the one for unsigned integers, as all addresses are subsets of the data >type u. You can compare a pointer with a char in Forth (this is even >formally ok with the type system from section 3.1.1), which does not make >sense, but the result is well-defined, because the comparison operator >used is just an integer comparison. The UB of pointer comparison is a good example of why UB makes sense. It is pretty hard to make pointer comparison an implementation defined behaviour and have definitions that stick. It is unnecessary in C, because C allows to convert (cast ) a pointer type to an integer type, which is implementation defined. So if one want to write a portable program, and write a memory manager on a single board computer one can do that in C. Just don't compare void * thingies, compare the corresponding integers. They probably are equivalent to what we do with Forth addresses, but the programmer has to check, and knows what to check. Now every programmer who reads the program is alerted, because these casts are tricky, don't go unnoticed and draw duely attention to non-portable behaviour. Caveat, the above applies to ANSI c. I don't claim expertise with newer standards, but the general point stands. Making everything implementation defined, is bad, because ub is ub because it should be avoided. Let's say we have null pointer access as ib. An implementation defines it as always returning zero. An other implementation defines it as actually accessing the physical address zero which may or may not be an access violation. So you port your programs and they are gonna crash. You've gained nothing by avoiding that the compiler hits you on the head with an undefined behaviour. The null pointer access made no sense in the first place. (We all know where that came from, porting sloppy MS-DOS programs to Unices.) >-- >Bernd Paysan 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-07 07:35 +0000 |
| Message-ID | <2016Mar7.083558@mips.complang.tuwien.ac.at> |
| In reply to | #45889 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>The UB of pointer comparison is a good example of why UB makes sense.
>It is pretty hard to make pointer comparison an implementation defined
>behaviour and have definitions that stick.
Actually, the memmove() case demonstrates the disadvantages of
undefined behaviour nicely. What the memmove() requires if the two
pointers do not point into the same aggregate object, is that the
comparison produces an arbitrary value; any will do and memmove() will
work fine. And that's what all hardware in the real world does. Yet,
the C standard specifies "undefined behaviour", so a perverse C
implementation can do funny "optimizations" based on that even on
hardware with a flat address space. And C compilers like GCC have
become pretty perverse over the years.
>It is unnecessary in C, because C allows to convert (cast ) a
>pointer type to an integer type, which is implementation defined.
>So if one want to write a portable program, and write a memory manager
>on a single board computer one can do that in C. Just don't compare
>void * thingies, compare the corresponding integers. They probably are
>equivalent to what we do with Forth addresses, but the programmer has
>to check, and knows what to check. Now every programmer who reads the
>program is alerted, because these casts are tricky, don't go unnoticed
>and draw duely attention to non-portable behaviour.
And that helps in which way? The C standard does not guarantee that a
memmove() with casts to integer does not work as intended, either.
>Let's say we have null pointer access as ib. An implementation defines it
>as always returning zero. An other implementation defines it as actually
>accessing the physical address zero which may or may not be an access violation.
>So you port your programs and they are gonna crash. You've gained nothing
>by avoiding that the compiler hits you on the head with an undefined
>behaviour. The null pointer access made no sense in the first place.
I have certainly gained something: Perverse compilers will no longer
"optimize" the program based on the assumption that undefined
behaviour does not happen. GCC miscompiled the Linux kernel based on
that "optimization" (as an excuse, in Linux user space that would have
been a real optimization, but then such code probably does not occur
in user-space programs; anyway the excuse by the GCC maintainers
writers was not about being configured for user space, but about
undefined behaviour.)
>(We all know where that came from, porting sloppy MS-DOS programs to
>Unices.)
"We all know" tries to convince the reader to avoid checking the
claim. In this case, read point 1 of
<http://www.catb.org/jargon/html/V/vaxocentrism.html>. Not mapping
the page including the address 0 was established quite a bit later.
- 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-07 12:40 +0000 |
| Message-ID | <56dd76d3$0$24031$e4fe514c@news.xs4all.nl> |
| In reply to | #45913 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >>The UB of pointer comparison is a good example of why UB makes sense. >>It is pretty hard to make pointer comparison an implementation defined >>behaviour and have definitions that stick. >Actually, the memmove() case demonstrates the disadvantages of >undefined behaviour nicely. What the memmove() requires if the two >pointers do not point into the same aggregate object, is that the >comparison produces an arbitrary value; any will do and memmove() will >work fine. And that's what all hardware in the real world does. Yet, >the C standard specifies "undefined behaviour", so a perverse C >implementation can do funny "optimizations" based on that even on >hardware with a flat address space. And C compilers like GCC have >become pretty perverse over the years. >>It is unnecessary in C, because C allows to convert (cast ) a >>pointer type to an integer type, which is implementation defined. >>So if one want to write a portable program, and write a memory manager >>on a single board computer one can do that in C. Just don't compare >>void * thingies, compare the corresponding integers. They probably are >>equivalent to what we do with Forth addresses, but the programmer has >>to check, and knows what to check. Now every programmer who reads the >>program is alerted, because these casts are tricky, don't go unnoticed >>and draw duely attention to non-portable behaviour. >And that helps in which way? The C standard does not guarantee that a >memmove() with casts to integer does not work as intended, either. It helps with knowing whether the pointers are the same. By casting the pointers separately and comparing the integers you have a valid, but maybe non-portable program. If I remember correctly you must be able to cast the integers back and get the right (void*) pointers. This guarantees that different pointers correspond to different integers. This means you can do your check about "pointing to different aggregate objects" without resorting to objectionable constructs. >>Let's say we have null pointer access as ib. An implementation defines it >>as always returning zero. An other implementation defines it as actually >>accessing the physical address zero which may or may not be an access violation. >>So you port your programs and they are gonna crash. You've gained nothing >>by avoiding that the compiler hits you on the head with an undefined >>behaviour. The null pointer access made no sense in the first place. >I have certainly gained something: Perverse compilers will no longer >"optimize" the program based on the assumption that undefined >behaviour does not happen. GCC miscompiled the Linux kernel based on >that "optimization" (as an excuse, in Linux user space that would have >been a real optimization, but then such code probably does not occur >in user-space programs; anyway the excuse by the GCC maintainers >writers was not about being configured for user space, but about >undefined behaviour.) That is a success. >>(We all know where that came from, porting sloppy MS-DOS programs to >>Unices.) >"We all know" tries to convince the reader to avoid checking the >claim. In this case, read point 1 of ><http://www.catb.org/jargon/html/V/vaxocentrism.html>. Not mapping >the page including the address 0 was established quite a bit later. Porting sloppy programs from VAX then? And how important are they compared to sloppy MS-DOS programs? >- 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/ -- 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 | Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> |
|---|---|
| Date | 2016-03-07 19:20 -0500 |
| Message-ID | <20160307192006.496fc534@_> |
| In reply to | #45877 |
On Sun, 6 Mar 2016 02:01:09 -0000 (UTC) Bernd Paysan <bernd.paysan@gmx.de> wrote: > Am Sat, 05 Mar 2016 20:33:16 -0500 schrieb Rod Pemberton: > > On Sun, 6 Mar 2016 00:50:53 -0000 (UTC) > > Bernd Paysan <bernd.paysan@gmx.de> wrote: > >> Yes, Forth is a simpler language, so we have less ambiguous > >> conditions than C has UBs. > > > > That makes no sense. > > > > A Forth word will pull whatever data it needs from the stack without > > being able to check that the data is correct before use of said > > data. There is no type checking in Forth. Therefore, every Forth > > word which removes data from the data stack potentially has UB. > > That there is no type-checking does not make the behavior undefined. > Example: In C, there is a UB for pointer comparison. In Forth, > pointers are just cell-sized data, and you can compare any two > pointers, and the result always only depends on their location in the > flat address space Forth has; you don't use a special > pointer-comparison instruction, but the one for unsigned integers, as > all addresses are subsets of the data type u. You can compare a > pointer with a char in Forth (this is even formally ok with the type > system from section 3.1.1), which does not make sense, but the result > is well-defined, because the comparison operator used is just an > integer comparison. > There is no guarantee in Forth that you're comparing the two expected pointers. You could be comparing garbage if there is a coding mistake, or a pointer with a string. Nobody knows for sure. You're saying that's not UB? ... At least the types passed to a procedure are checked to be compatible with each other in C. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-08 00:49 +0000 |
| Message-ID | <nbl7ht$e55$1@dont-email.me> |
| In reply to | #45928 |
Am Mon, 07 Mar 2016 19:20:06 -0500 schrieb Rod Pemberton: > There is no guarantee in Forth that you're comparing the two expected > pointers. You could be comparing garbage if there is a coding mistake, > or a pointer with a string. Nobody knows for sure. You're saying that's > not UB? ... At least the types passed to a procedure are checked to be > compatible with each other in C. All what Forth compares is two cell-sized integers. That always gives a result, either true or false, and it only depends on the actual bits in that two numbers. There is no garbage on that level, bits are always 1 or 0. There is no possibility this comparison formats your hard disk or produces nasal daemons: The result can only be true or false. There's no ambiguous condition listed in U<, which you would use to compare pointers (nor is there one in <). There is no typecast, pointers *are* integers in Forth. Of course the result might differ from what the programmer wants. No programming language does "do what I mean", though some try harder than others; Forth doesn't try. The result is a simpler language with less undefined corners, and the cost is possible confusion of the programmer, because Forth doesn't (and can't) check things other programming languages check. So you have to test the actual program, successfully compiling it doesn't say much. -- 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-06 02:20 -0600 |
| Message-ID | <2_Sdnfj21ruqdUbLnZ2dnUU78InNnZ2d@supernews.com> |
| In reply to | #45867 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Am Sat, 05 Mar 2016 15:42:48 -0600 schrieb Andrew Haley: > > 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. That's not true, and in the general case isn't possible without a great deal of overhead. As the standard says, it is permissible to state that the behavior is unspecifiable and to explain the circumstances and reasons why this is so. Such reasons might be "because I'm a bastard" or "because I'm lazy." In practice it's more likely to be "because I don't check for this condition." Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-07 00:35 +0000 |
| Message-ID | <nbiid0$it8$2@dont-email.me> |
| In reply to | #45882 |
Am Sun, 06 Mar 2016 02:20:07 -0600 schrieb Andrew Haley: > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> Am Sat, 05 Mar 2016 15:42:48 -0600 schrieb Andrew Haley: >> >> 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. > > That's not true, and in the general case isn't possible without a great > deal of overhead. As the standard says, it is permissible to state that > the behavior is unspecifiable and to explain the circumstances and > reasons why this is so. Such reasons might be "because I'm a bastard" > or "because I'm lazy." In practice it's more likely to be "because I > don't check for this condition." "not checked" is a valid answer. E.g. Gforth states for "unavailability of the loop control parameters" that this is not checked, but the two topmost return stack elements are supposed to be the loop control parameters. This defines the behavior. In a number of cases, we say that behavior is processor-dependent (e.g. unaligned memory access), or OS-dependent (error codes for file accesses, allowed file characters, etc.). IMHO the worst part of our ambiguous conditions are those where we refer to 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-07 02:53 -0600 |
| Message-ID | <etmdnUoZ_uQc3EDLnZ2dnUU78WnNnZ2d@supernews.com> |
| In reply to | #45906 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Am Sun, 06 Mar 2016 02:20:07 -0600 schrieb Andrew Haley: > >> Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> Am Sat, 05 Mar 2016 15:42:48 -0600 schrieb Andrew Haley: >>> >>> 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. >> >> That's not true, and in the general case isn't possible without a >> great deal of overhead. As the standard says, it is permissible to >> state that the behavior is unspecifiable and to explain the >> circumstances and reasons why this is so. Such reasons might be >> "because I'm a bastard" or "because I'm lazy." In practice it's >> more likely to be "because I don't check for this condition." > > "not checked" is a valid answer. E.g. Gforth states for > "unavailability of the loop control parameters" that this is not > checked, but the two topmost return stack elements are supposed to > be the loop control parameters. This defines the behavior. And there's nothing to stop anyone from defining all ambiguous conditions as unspecifiable. What you call implementation-defined behaviour is not, in fact defined at all, because the standard does not require it to be constrained in any way. The whole system might crash. Java is quite different: there are some behaviours which are implementation-defined or in some way unpredictable, but they are still constrained in what they can do. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-07 16:07 +0000 |
| Message-ID | <nbk90j$fcr$1@dont-email.me> |
| In reply to | #45914 |
Am Mon, 07 Mar 2016 02:53:21 -0600 schrieb Andrew Haley: > And there's nothing to stop anyone from defining all ambiguous > conditions as unspecifiable. Of course that's possible, but if you read that section of the manual, you know that you should get a better Forth. The problem with GCC is the low quality of implementation, and that it is not flagged as such a low- quality implementation by a clear notice in the manual. I suggest the maintainers write in clear words at the beginning of the GNU Compiler Collection: "We are dicks, and will break your programs. If you don't like that, stay away from the Gnasty Nasaldemon Unfriendly Compiler Collection". > What you call implementation-defined > behaviour is not, in fact defined at all, because the standard does not > require it to be constrained in any way. The whole system might crash. > Java is quite different: there are some behaviours which are > implementation-defined or in some way unpredictable, but they are still > constrained in what they can do. Apparently you are under the impression that crashing is undefined behavior. I don't quite agree. Forth is not a safe language as Java, so programs have lots of potentially malicious powers, and the way they modify the system can be anticipated before by looking at the action the buggy program wants to perform. Look: If you write a program in assembler, you are also likely to crash your program. The underlying architecture however is completely defined, so the crash is determined by the actual operations that led to the crash. It is not turning any bits from 0 or 1 to 'x'. 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. -- 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-08 05:17 -0600 |
| Message-ID | <8oqdnbROEJ0pKUPLnZ2dnUU7-YHNnZ2d@supernews.com> |
| In reply to | #45921 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Am Mon, 07 Mar 2016 02:53:21 -0600 schrieb Andrew Haley: >> And there's nothing to stop anyone from defining all ambiguous >> conditions as unspecifiable. > > Of course that's possible, but if you read that section of the manual, > you know that you should get a better Forth. I think that's a pious hope. I don't believe that there is anything in that section of the standard which requires it; a "should" is not a "shall". >> What you call implementation-defined behaviour is not, in fact >> defined at all, because the standard does not require it to be >> constrained in any way. The whole system might crash. Java is >> quite different: there are some behaviours which are >> implementation-defined or in some way unpredictable, but they are >> still constrained in what they can do. > > Apparently you are under the impression that crashing is undefined > behavior. I don't quite agree. Oh dear. Well, a crash can do anything: lose the vehicle, cause the patient to die, etc. 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. > 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? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-08 22:01 +0000 |
| Message-ID | <nbni3v$cs0$1@dont-email.me> |
| In reply to | #45938 |
Am Tue, 08 Mar 2016 05:17:08 -0600 schrieb Andrew Haley: > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> Apparently you are under the impression that crashing is undefined >> behavior. I don't quite agree. > > Oh dear. Well, a crash can do anything: lose the vehicle, cause the > patient to die, etc. Any bug can do that, even a bug that is perfectly following well- specified behavior. Remember that mars lander that had some imperial and some metric units? Or the Hubble mirror grinder? The result: disaster. The calculation: fully within the spec of the programming language. 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. > 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. 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. So in Forth I can write : test-wrapv -1 1 rshift dup 1+ < IF true abort" some fuckup in the system" ELSE ." everything ok" cr THEN ; test-wrapv >> 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". -- 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-09 03:14 -0600 |
| Message-ID | <jYCdndgn2-YQdELLnZ2dnUU78QGdnZ2d@supernews.com> |
| In reply to | #45941 |
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. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-03-09 11:17 +0000 |
| Message-ID | <56e00631$0$24126$e4fe514c@news.xs4all.nl> |
| In reply to | #45948 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >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. In indirect threaded Forth the equivalent is the change of the data field that points to indirect threaded code. That is even worse, especially in a Forth like ciforth that entitles the programmer tochange it to achieve vectored execution. <SNIP> >>>> 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. yourforth is my attempt at the simplest Forth possible. ABORT" seems to be about equal implementation effort as THROW and you need an error mechanism anyway. So in my book THROW is there right in the middle of a Forth core. (I left out ABORT" in yourforth. I'd say it is ripe for obsolescence.) >Andrew. 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-09 23:58 +0000 |
| Message-ID | <nbqdbm$823$1@dont-email.me> |
| In reply to | #45948 |
Am Wed, 09 Mar 2016 03:14:53 -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. That wasn't the point, the language specification would declare that IB. The implementation then can specify what happens when you write to the code field, and maybe you have entitlements like ' FOO PATCHES BAR, which changes the data field of BAR to start with a BRANCH to the start of FOO if FOO is a colon definition, otherwise to invoke FOO and then EXIT. 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. So an IB for changing the code or data field of a word results in changed behavior (unless the system is in Flash, where it is not possible to write again), and an IB for a pointer comparison in C could say that the result of the comparison is always true or false, but for comparison between different objects, the actual computation is IB, so the result is unpredictable (but always 0 or 1, and no exceptions). Then the implementer still can be a dick and say "hey, I don't know how I compute the pointer differences of different objects, and it will change tomorrow", but the memmove code will always work. -- 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-10 04:45 -0600 |
| Message-ID | <BPmdnTOAsuSizXzLnZ2dnUU7-a_NnZ2d@supernews.com> |
| In reply to | #45951 |
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. > So an IB for changing the code or data field of a word results in > changed behavior ... which is unspecified and therefore undefined. As discussed, a wild jump can do anything, including disabling the computer so that it can't reboot. > (unless the system is in Flash, where it is not possible to write > again), and an IB for a pointer comparison in C could say that the > result of the comparison is always true or false, but for comparison > between different objects, the actual computation is IB, so the > result is unpredictable (but always 0 or 1, and no exceptions). > Then the implementer still can be a dick and say "hey, I don't know > how I compute the pointer differences of different objects, and it > will change tomorrow", but the memmove code will always work. That would be better for memmove, yes. But that's specific to pointer comparisons. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-10 11:39 +0000 |
| Message-ID | <2016Mar10.123904@mips.complang.tuwien.ac.at> |
| In reply to | #45955 |
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.
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.
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.
- 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-10 13:29 +0000 |
| Message-ID | <56e176bb$0$24124$e4fe514c@news.xs4all.nl> |
| In reply to | #45956 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >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. >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. >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. It would probably mean what uncaught exceptions are for: a severe program error. >The only thing that can do pretty wild things in user space are wild >stores and wild jumps. >- 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]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web