Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #42204 > unrolled thread
| Started by | Chris Curl <ccurl609@gmail.com> |
|---|---|
| First post | 2015-09-26 15:17 -0700 |
| Last post | 2015-10-31 10:44 -0700 |
| Articles | 20 on this page of 144 — 28 participants |
Back to article view | Back to comp.lang.forth
New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-26 15:17 -0700
Re: New to the group mentificium@gmail.com - 2015-09-26 17:35 -0700
Re: New to the group hughaguilar96@gmail.com - 2015-09-26 21:16 -0700
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-27 07:27 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-27 14:43 -0400
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-27 13:05 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-27 12:57 -1000
Re: New to the group Paul Rubin <no.email@nospam.invalid> - 2015-09-27 17:00 -0700
Re: New to the group hughaguilar96@gmail.com - 2015-09-27 17:16 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-27 20:31 -0400
Re: New to the group jfong@ms4.hinet.net - 2015-09-27 18:57 -0700
Re: New to the group hughaguilar96@gmail.com - 2015-09-27 19:37 -0700
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-27 20:53 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-27 19:02 -1000
Re: New to the group hughaguilar96@gmail.com - 2015-09-27 23:33 -0700
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-28 04:51 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-28 12:39 -0400
Re: New to the group Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-09-28 14:29 +0200
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-28 07:18 -0700
Re: New to the group foxaudioresearch@gmail.com - 2015-09-28 08:07 -0700
Re: New to the group Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-09-28 17:23 +0200
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-28 11:16 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-28 14:25 -0400
Re: New to the group anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-29 09:05 +0000
Re: New to the group Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-09-28 20:31 +0200
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-28 13:20 -0700
Re: New to the group Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-09-28 22:52 +0200
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-28 16:40 -0700
Re: New to the group Alfred Singlestone <vitonis@gmail.com> - 2015-09-28 08:41 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-28 11:41 -1000
Re: New to the group hughaguilar96@gmail.com - 2015-09-28 21:33 -0700
Re: New to the group jfong@ms4.hinet.net - 2015-09-28 19:13 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-29 00:51 -0400
Re: New to the group jfong@ms4.hinet.net - 2015-09-29 18:26 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-29 21:55 -0400
Re: New to the group Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-09-30 08:29 +0100
Re: New to the group jfong@ms4.hinet.net - 2015-09-29 18:52 -0700
Re: New to the group hughaguilar96@gmail.com - 2015-09-29 00:29 -0700
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-29 04:40 -0700
Re: New to the group Mark Wills <markwills1970@gmail.com> - 2015-09-29 05:24 -0700
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-29 07:33 -0700
Re: New to the group hughaguilar96@gmail.com - 2015-09-29 14:11 -0700
Re: New to the group "WJ" <w_a_x_man@yahoo.com> - 2015-09-29 16:46 +0000
Re: New to the group hughaguilar96@gmail.com - 2015-09-29 14:15 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-29 17:34 -0400
Re: New to the group "WJ" <w_a_x_man@yahoo.com> - 2015-09-30 00:07 +0000
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-27 10:54 -0700
Re: New to the group Paul Rubin <no.email@nospam.invalid> - 2015-09-26 22:37 -0700
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-27 10:51 -0700
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-29 17:15 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-29 21:58 -0400
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-29 22:03 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-29 21:32 -1000
Re: New to the group Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-09-30 09:06 +0100
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-30 08:58 -1000
Re: New to the group Mark Wills <markwills1970@gmail.com> - 2015-09-30 23:55 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-30 21:28 -1000
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-01 08:25 -0400
Re: New to the group hughaguilar96@gmail.com - 2015-10-01 09:33 -0700
Re: New to the group hughaguilar96@gmail.com - 2015-09-30 16:21 -0700
Re: New to the group "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-30 21:03 -0400
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-30 19:34 -1000
Re: New to the group hughaguilar96@gmail.com - 2015-09-30 23:47 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-01 08:31 -0400
Re: New to the group "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-02 00:30 -0400
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-01 19:22 -1000
Re: New to the group hughaguilar96@gmail.com - 2015-10-01 23:52 -0700
Re: New to the group Mark Wills <markwills1970@gmail.com> - 2015-10-02 01:52 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-02 08:36 -1000
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-02 17:00 -0400
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-10-02 14:46 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-02 18:10 -0400
Re: New to the group Paul Rubin <no.email@nospam.invalid> - 2015-10-02 16:08 -0700
Re: New to the group "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-02 20:44 -0400
Re: New to the group David Thompson <dave.thompson2@verizon.net> - 2015-10-31 06:54 -0400
Re: New to the group "Rod Pemberton" <too@zxcvfeqad.cdm> - 2015-11-02 02:34 -0500
Re: New to the group David Thompson <dave.thompson2@verizon.net> - 2015-12-22 06:45 -0500
Re: New to the group "Rod Pemberton" <too@zxcvfeqad.cdm> - 2015-11-02 02:34 -0500
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-02 15:16 -1000
Re: New to the group Paul Rubin <no.email@nospam.invalid> - 2015-10-02 18:21 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-02 15:38 -1000
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-02 22:13 -0400
Re: New to the group Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-10-03 22:24 +0100
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-03 17:33 -0400
Re: New to the group hughaguilar96@gmail.com - 2015-09-30 17:00 -0700
Re: New to the group "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-30 20:38 -0400
Re: New to the group Walter Banks <walter@bytecraft.com> - 2015-10-02 14:37 -0400
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-02 17:01 -0400
Re: New to the group hughaguilar96@gmail.com - 2015-10-02 23:35 -0700
Re: New to the group "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-30 18:11 -0400
Re: New to the group Coos Haak <chforth@hccnet.nl> - 2015-10-01 02:13 +0200
Re: New to the group Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-09-30 08:38 +0100
Re: New to the group Walter Banks <walter@bytecraft.com> - 2015-09-30 10:58 -0400
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-10-01 06:04 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-01 09:46 -0400
Re: New to the group anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-08 06:07 +0000
Re: New to the group Alfred Singlestone <vitonis@gmail.com> - 2015-10-09 04:04 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-09 10:29 -0400
Re: New to the group anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-09 15:30 +0000
Re: New to the group lehs <skydda.barnen@gmail.com> - 2015-10-03 00:19 -0700
Re: New to the group visualforth@rocketmail.com - 2015-10-03 17:01 -0700
Re: New to the group anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-08 06:38 +0000
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-07 21:15 -1000
Minimal wordset (was: New to the group) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-08 13:39 +0000
Re: Minimal wordset (was: New to the group) JUERGEN <epldfpga@aol.com> - 2015-10-08 08:13 -0700
Re: Minimal wordset (was: New to the group) Mark Wills <markwills1970@gmail.com> - 2015-10-09 00:55 -0700
Re: Minimal wordset Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-09 10:43 +0200
Re: Minimal wordset Chris Curl <ccurl609@gmail.com> - 2015-10-09 06:56 -0700
Re: Minimal wordset Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-09 19:44 +0200
Re: Minimal wordset Paul Rubin <no.email@nospam.invalid> - 2015-10-09 14:02 -0700
Re: Minimal wordset Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-10-10 09:44 +0100
Re: Minimal wordset anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-10 11:36 +0000
Re: Minimal wordset lehs <skydda.barnen@gmail.com> - 2015-10-09 08:40 -0700
Re: Minimal wordset Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-09 19:53 +0200
Re: Minimal wordset lehs <skydda.barnen@gmail.com> - 2015-10-09 11:22 -0700
Re: Minimal wordset JUERGEN <epldfpga@aol.com> - 2015-10-09 11:33 -0700
Re: Minimal wordset Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-09 20:38 +0200
Re: Minimal wordset stephen@mpeforth.com (Stephen Pelc) - 2015-10-09 20:56 +0000
Re: Minimal wordset rickman <gnuarm@gmail.com> - 2015-11-01 20:10 -0500
Re: Minimal wordset Coos Haak <chforth@hccnet.nl> - 2015-11-02 03:05 +0100
Re: Minimal wordset "Elizabeth D. Rather" <erather@forth.com> - 2015-11-01 16:08 -1000
Re: Minimal wordset stephen@mpeforth.com (Stephen Pelc) - 2015-11-02 09:35 +0000
Re: Minimal wordset anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 12:42 +0000
Re: Minimal wordset humptydumpty <ouatubi@gmail.com> - 2015-11-08 23:22 -0800
Re: Minimal wordset rickman <gnuarm@gmail.com> - 2015-11-03 11:25 -0500
Re: Minimal wordset stephen@mpeforth.com (Stephen Pelc) - 2015-11-03 19:36 +0000
Re: Minimal wordset "HAA" <someone@microsoft.com> - 2015-11-08 12:56 +1100
Re: Minimal wordset stephen@mpeforth.com (Stephen Pelc) - 2015-11-08 16:14 +0000
Re: Minimal wordset "HAA" <someone@microsoft.com> - 2015-11-09 11:55 +1100
Re: Minimal wordset anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 09:41 +0000
Re: Minimal wordset rickman <gnuarm@gmail.com> - 2015-11-03 11:29 -0500
Re: Minimal wordset anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 17:01 +0000
Re: Minimal wordset JUERGEN <epldfpga@aol.com> - 2015-10-09 11:27 -0700
Re: Minimal wordset (was: New to the group) "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-09 23:11 -0400
Re: Minimal wordset (was: New to the group) Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-10-10 08:38 +0100
Re: New to the group dunno <dunno@dunno.dunno> - 2015-10-14 23:14 +0000
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-14 16:21 -1000
Re: New to the group anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-15 08:46 +0000
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-10-03 09:23 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-03 09:19 -1000
Re: New to the group lehs <skydda.barnen@gmail.com> - 2015-10-08 05:24 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-08 08:22 -1000
Re: New to the group lehs <skydda.barnen@gmail.com> - 2015-10-09 08:37 -0700
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-10-31 10:44 -0700
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-09-30 21:03 -0400 |
| Message-ID | <op.x5syj4juyfako5@localhost> |
| In reply to | #42285 |
On Wed, 30 Sep 2015 19:21:04 -0400, <hughaguilar96@gmail.com> wrote: > The word "ambiguous" doesn't belong in a language standard, because > it doesn't standardize anything. Errors should not result in ambiguous > conditions --- they should be handled in a consistent well-defined manner. Exactly. Such situations are potentially exploitable by hackers depending on what occurs for a specific Forth the "ambiguous" situation. The result is that to ensure safety _all_ such situations should be blocked, which most likely will cause Forth programs using established historical Forth behaviors to crash, halt, hang, or function incorrectly. Didn't you learn this already with your ANS experience? > The situation is actually much worse than Chris realizes. Over 50 > of the words in the standard have this sentence in their definition: > "Interpretation semantics for this word are undefined." Yes, you almost need a STATE-aware Forth with another word like IMMEDIATE or SMUDGE just to mark the "over 50" words with undefined execution semantics. How else can you selectively enable and disable execution semantics for these words? ... Anton is bound to respond to this by stating that a STATE-aware Forth is not required. > Rather than define this as an error however, the ANS-Forth document > defines it as "undefined" (section 6.1.1700 above), and "undefined" > is just another word for "ambiguous" because it doesn't standardize > anything. So, you disagree with Ms. Rather on Forth-83 being a bad standard? It eliminated "ambiguous" situations by specifically defining the integer sizes, etc. > Now the weirdness deepens! We have section 4.1.2 with the ominous > heading: "Ambiguous Conditions." One of the ambiguous conditions > is: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', > 6.1.1550 FIND, etc.) of a definition with undefined interpretation > semantics." What this means is that using tick or FIND on a word > such as IF is an ambiguous condition, and anything can happen. With "over 50" such words with "ambiguous" conditions, you'd really have to wonder what the point of having a mandatory CORE and CORE EXT set of words is, wouldn't you? ... With roughly 133 CORE and 46 CORE EXT words, that would mean only 62% of CORE words and only 72% of CORE and CORE EXT are useable interactively. It would almost seem like they don't want you to use Forth interactively anymore Hugh ... I'm just waiting for you to stop ranting about Forth and embrace C. Supposedly, you already programmed in C before. So, I don't know why the delay in your conversion remains. Rod Pemberton -- Just how many texting and calendar apps does humanity need? Just how many food articles from neurotic millenials do we need?
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-09-30 19:34 -1000 |
| Message-ID | <-9udnUrFSOV8WJHLnZ2dnUU7-N-dnZ2d@supernews.com> |
| In reply to | #42291 |
On 9/30/15 3:03 PM, Rod Pemberton wrote: > On Wed, 30 Sep 2015 19:21:04 -0400, <hughaguilar96@gmail.com> wrote: > >> The word "ambiguous" doesn't belong in a language standard, because >> it doesn't standardize anything. Errors should not result in ambiguous >> conditions --- they should be handled in a consistent well-defined >> manner. > > Exactly. Not so obvious. "Ambiguous conditions" generally fall into two categories: 1. Things that are basically errors but the correct response depends on the application or the situation. Example: attempt to divide by zero. In some circumstances, the correct response might be to abort with an error message for the user; in others (e.g., an embedded system with no user interface) it might be some other recovery option altogether. Most systems use THROW codes for these, but since CATCH/THROW is optional, it's not required. 2. Things that aren't normally allowed but which some implementations might want to support in some fashion. Example: using a compiler directive (such as IF) interactively. Most of the time, IF compiles a forward branch and leaves the address of the cell reserved for its destination on the stack to be filled by ELSE or THEN. That makes no sense when you're just typing, so systems might wish to issue an error message. But some systems, such as Open Firmware, let you use structures (IF ... THEN, DO ... LOOP, etc.) either at the keyboard or in program source, in which case they compile something which is executed once at the end of the line and then thrown away. In other words, it's an optional feature. Generally, one shouldn't get fussed when reading that a certain condition is "ambiguous." Just take the message as, "don't do that" and (if you care) look at the documentation for the system in question to see what it does. 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-09-30 23:47 -0700 |
| Message-ID | <fc467fff-d068-4eb7-9962-3aac8b120368@googlegroups.com> |
| In reply to | #42293 |
On Wednesday, September 30, 2015 at 10:34:27 PM UTC-7, Elizabeth D. Rather wrote: > Generally, one shouldn't get fussed when reading that a certain > condition is "ambiguous." Just take the message as, "don't do that" and > (if you care) look at the documentation for the system in question to > see what it does. So, this explains why ticking IF causes gForth to abort --- I should have known: "don't do that!" Perhaps you are explaining why IF does have an xt in VFX, but the xt will abort when executed (no matter what STATE is at the time) --- it is a non-executable execution-token. Maybe you are explaining why FIND in gForth returns different xt values for IF depending upon what STATE is at the time that FIND executes. All of this is allowed by the ANS-Forth document --- the bad thing about ambiguity is that anything can happen, but whatever happens is legal ANS-Forth. Anyway, my disambiguifiers fix the problem.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-10-01 08:31 -0400 |
| Message-ID | <muj8v3$lu9$1@dont-email.me> |
| In reply to | #42294 |
On 10/1/2015 2:47 AM, hughaguilar96@gmail.com wrote: > On Wednesday, September 30, 2015 at 10:34:27 PM UTC-7, Elizabeth D. Rather wrote: >> Generally, one shouldn't get fussed when reading that a certain >> condition is "ambiguous." Just take the message as, "don't do that" and >> (if you care) look at the documentation for the system in question to >> see what it does. > > So, this explains why ticking IF causes gForth to abort --- I should have known: "don't do that!" > > Perhaps you are explaining why IF does have an xt in VFX, but the xt will abort when executed (no matter what STATE is at the time) --- it is a non-executable execution-token. > > Maybe you are explaining why FIND in gForth returns different xt values for IF depending upon what STATE is at the time that FIND executes. > > All of this is allowed by the ANS-Forth document --- the bad thing about ambiguity is that anything can happen, but whatever happens is legal ANS-Forth. I'm sure I'm not the only one who is tired of Hugh's rantings on this issue. IF does not have defined execution semantics. So why would anyone expect IF to have an XT and if a value were returned by tick, why would they expect it to do anything useful when executed? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-10-02 00:30 -0400 |
| Message-ID | <op.x5u2s0goyfako5@localhost> |
| In reply to | #42299 |
On Thu, 01 Oct 2015 08:31:21 -0400, rickman <gnuarm@gmail.com> wrote: > On 10/1/2015 2:47 AM, hughaguilar96@gmail.com wrote: >> On Wednesday, September 30, 2015 at 10:34:27 PM UTC-7, Elizabeth D. Rather wrote: >>> Generally, one shouldn't get fussed when reading that a certain >>> condition is "ambiguous." Just take the message as, "don't do that" and >>> (if you care) look at the documentation for the system in question to >>> see what it does. >> >> So, this explains why ticking IF causes gForth to abort --- I should >> have known: "don't do that!" >> >> Perhaps you are explaining why IF does have an xt in VFX, but the xt >> will abort when executed (no matter what STATE is at the time) --- it >> is a non-executable execution-token. >> >> Maybe you are explaining why FIND in gForth returns different xt >> values for IF depending upon what STATE is at the time that FIND executes. >> >> All of this is allowed by the ANS-Forth document --- the bad thing about >> ambiguity is that anything can happen, but whatever happens is legal ANS-Forth. > > I'm sure I'm not the only one who is tired of Hugh's rantings on this > issue. IF does not have defined execution semantics. So why would > anyone expect IF to have an XT and if a value were returned by tick, why > would they expect it to do anything useful when executed? > I only like Hugh's rants when I can make fun of him ... Of course, I also bring up important points which he ignores also. But, all of that still doesn't mean his point was unimportant. ISTM that older Forth standards would return the XT or equivalent (PFA) for ' (tick) if the word was found in the dictionary and/or vocabulary regardless of any execution semantics or immediacy etc. Therefore, *NOT* returning an XT for a word that's in the dictionary because it doesn't have any execution or interpration semantics would seem to be a departure from the prior Forth standards and/or historical Forth behavior. As Hugh noted, code which expects historical behaviors may break with ANS since ANS apparently made little to no effort to preserve such behaviors. I.e., his apparent claim that ANS code is non-portable would seem to be valid in the sense that the code would break on pre-ANS Forths. Although, I don't think he mentioned pre-ANS Forths anywhere in his claims. Rod Pemberton -- Just how many texting and calendar apps does humanity need? Just how many food articles from neurotic millenials do we need?
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-10-01 19:22 -1000 |
| Message-ID | <xOydnQxClo8XiZPLnZ2dnUU7-VednZ2d@supernews.com> |
| In reply to | #42306 |
On 10/1/15 6:30 PM, Rod Pemberton wrote: > On Thu, 01 Oct 2015 08:31:21 -0400, rickman <gnuarm@gmail.com> wrote: > >> On 10/1/2015 2:47 AM, hughaguilar96@gmail.com wrote: >>> On Wednesday, September 30, 2015 at 10:34:27 PM UTC-7, Elizabeth D. >>> Rather wrote: > >>>> Generally, one shouldn't get fussed when reading that a certain >>>> condition is "ambiguous." Just take the message as, "don't do that" and >>>> (if you care) look at the documentation for the system in question to >>>> see what it does. >>> >>> So, this explains why ticking IF causes gForth to abort --- I should >>> have known: "don't do that!" >>> >>> Perhaps you are explaining why IF does have an xt in VFX, but the xt >>> will abort when executed (no matter what STATE is at the time) --- it >>> is a non-executable execution-token. >>> >>> Maybe you are explaining why FIND in gForth returns different xt >>> values for IF depending upon what STATE is at the time that FIND >>> executes. >>> >>> All of this is allowed by the ANS-Forth document --- the bad thing about >>> ambiguity is that anything can happen, but whatever happens is legal >>> ANS-Forth. >> >> I'm sure I'm not the only one who is tired of Hugh's rantings on this >> issue. IF does not have defined execution semantics. So why would >> anyone expect IF to have an XT and if a value were returned by tick, why >> would they expect it to do anything useful when executed? >> > > I only like Hugh's rants when I can make fun of him ... > Of course, I also bring up important points which he ignores also. > > But, all of that still doesn't mean his point was unimportant. > > ISTM that older Forth standards would return the XT or equivalent > (PFA) for ' (tick) if the word was found in the dictionary and/or > vocabulary regardless of any execution semantics or immediacy etc. > Therefore, *NOT* returning an XT for a word that's in the dictionary > because it doesn't have any execution or interpration semantics would > seem to be a departure from the prior Forth standards and/or historical > Forth behavior. As Hugh noted, code which expects historical behaviors > may break with ANS since ANS apparently made little to no effort to > preserve such behaviors. I.e., his apparent claim that ANS code is > non-portable would seem to be valid in the sense that the code would > break on pre-ANS Forths. Although, I don't think he mentioned pre-ANS > Forths anywhere in his claims. In the first place, any standard can only offer portability across conforming systems. Although the ANS Forth process tried to avoid "breaking" Forth83 programs (and went to some lengths to document changes so anyone would know), the fact that it can't guarantee portability for pre-ANS programs shouldn't be unexpected or a source of valid criticism. Forth79's ' was state-smart; it performed the function of ['] if it appeared in compilation mode. Forth83 fixed that. Neither addresses the awkward question of what one can actually do with the "compilation address" of a compiler directive such as IF. Odds are, if you type: ' IF EXECUTE ...you might get a branch compiled at the next available location in the dictionary. If you aren't in the middle of a definition and in compilation mode, that will be useless, and a source of great confusion. On some systems, in fact, you might get an abort. On still others, you might crash. In other words, it's hard to say what the "historical behavior" in this case would even be. The ANS Forth TC actually received quite a number of complaints about difficulties caused by misunderstandings about what one can do with the results of ' or ['] used on compiler directives, and spent a lot of time discussing an appropriate solution, before finally concluding that it was, in fact, an inappropriate thing to do in most systems, and therefore the best solution was to define "compilation semantics" (behavior during compilation) and "interpretation semantics" (behavior during interpretation) and declare that compiler directives did not have standard, defined interpretation semantics. Therefore, the standard can't guarantee what will happen if you just type IF at the command line. This is not, in fact, a change from prior standards, because what would happen in that case was never clearly specified. It was *always* ambiguous. What ANS Forth actually did was *warn* users of this situation. 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-10-01 23:52 -0700 |
| Message-ID | <ae0e2738-0773-48c3-98a5-703c4aa520d8@googlegroups.com> |
| In reply to | #42308 |
On Thursday, October 1, 2015 at 10:22:20 PM UTC-7, Elizabeth D. Rather wrote:
> On 10/1/15 6:30 PM, Rod Pemberton wrote:
> > On Thu, 01 Oct 2015 08:31:21 -0400, rickman <gnuarm@gmail.com> wrote:
> >
> >> On 10/1/2015 2:47 AM, hughaguilar96@gmail.com wrote:
> >>> On Wednesday, September 30, 2015 at 10:34:27 PM UTC-7, Elizabeth D.
> >>> Rather wrote:
> >
> >>>> Generally, one shouldn't get fussed when reading that a certain
> >>>> condition is "ambiguous." Just take the message as, "don't do that" and
> >>>> (if you care) look at the documentation for the system in question to
> >>>> see what it does.
> >>>
> >>> So, this explains why ticking IF causes gForth to abort --- I should
> >>> have known: "don't do that!"
> >>>
> >>> Perhaps you are explaining why IF does have an xt in VFX, but the xt
> >>> will abort when executed (no matter what STATE is at the time) --- it
> >>> is a non-executable execution-token.
> >>>
> >>> Maybe you are explaining why FIND in gForth returns different xt
> >>> values for IF depending upon what STATE is at the time that FIND
> >>> executes.
> >>>
> >>> All of this is allowed by the ANS-Forth document --- the bad thing about
> >>> ambiguity is that anything can happen, but whatever happens is legal
> >>> ANS-Forth.
> >>
> >> I'm sure I'm not the only one who is tired of Hugh's rantings on this
> >> issue. IF does not have defined execution semantics. So why would
> >> anyone expect IF to have an XT and if a value were returned by tick, why
> >> would they expect it to do anything useful when executed?
> >>
> >
> > I only like Hugh's rants when I can make fun of him ...
> > Of course, I also bring up important points which he ignores also.
> >
> > But, all of that still doesn't mean his point was unimportant.
> >
> > ISTM that older Forth standards would return the XT or equivalent
> > (PFA) for ' (tick) if the word was found in the dictionary and/or
> > vocabulary regardless of any execution semantics or immediacy etc.
> > Therefore, *NOT* returning an XT for a word that's in the dictionary
> > because it doesn't have any execution or interpration semantics would
> > seem to be a departure from the prior Forth standards and/or historical
> > Forth behavior. As Hugh noted, code which expects historical behaviors
> > may break with ANS since ANS apparently made little to no effort to
> > preserve such behaviors. I.e., his apparent claim that ANS code is
> > non-portable would seem to be valid in the sense that the code would
> > break on pre-ANS Forths. Although, I don't think he mentioned pre-ANS
> > Forths anywhere in his claims.
>
> In the first place, any standard can only offer portability across
> conforming systems. Although the ANS Forth process tried to avoid
> "breaking" Forth83 programs (and went to some lengths to document
> changes so anyone would know), the fact that it can't guarantee
> portability for pre-ANS programs shouldn't be unexpected or a source of
> valid criticism.
>
> Forth79's ' was state-smart; it performed the function of ['] if it
> appeared in compilation mode. Forth83 fixed that. Neither addresses the
> awkward question of what one can actually do with the "compilation
> address" of a compiler directive such as IF. Odds are, if you type:
>
> ' IF EXECUTE
>
> ...you might get a branch compiled at the next available location in the
> dictionary. If you aren't in the middle of a definition and in
> compilation mode, that will be useless, and a source of great confusion.
> On some systems, in fact, you might get an abort. On still others, you
> might crash. In other words, it's hard to say what the "historical
> behavior" in this case would even be.
>
> The ANS Forth TC actually received quite a number of complaints about
> difficulties caused by misunderstandings about what one can do with the
> results of ' or ['] used on compiler directives, and spent a lot of time
> discussing an appropriate solution, before finally concluding that it
> was, in fact, an inappropriate thing to do in most systems, and
> therefore the best solution was to define "compilation semantics"
> (behavior during compilation) and "interpretation semantics" (behavior
> during interpretation) and declare that compiler directives did not have
> standard, defined interpretation semantics. Therefore, the standard
> can't guarantee what will happen if you just type IF at the command
> line. This is not, in fact, a change from prior standards, because what
> would happen in that case was never clearly specified. It was *always*
> ambiguous. What ANS Forth actually did was *warn* users of this situation.
>
> Cheers,
> Elizabeth
This is a total straw-man argument --- your typical strategy.
I wasn't trying to execute the xt of IF in interpretation mode, I was trying to execute the xt of IF in compilation mode, which has always worked prior to ANS-Forth.
This is the thread:
https://groups.google.com/forum/#!searchin/comp.lang.forth/bug$20vfx/comp.lang.forth/oXXQAGDKP7w/iMLU1ExXOAIJ
This is what I said:
On Tuesday, March 31, 2015 at 3:13:14 PM UTC-7, hughag...@gmail.com wrote:
> : my-if [ ' if ] literal execute ; immediate ok
> : ttt ( flag -- ) my-if ." true " else ." false " then ;
> Err# -14 ERR: Attempt to interpret a compile only definition.
> -> : ttt ( flag -- ) my-if ." true " else ." false " then ;
> ^
> see my-if
> MY-IF (is IMMEDIATE)
> ( 004C7A80 E89B23F4FF ) CALL 00409E20 IF
> ( 004C7A85 C3 ) NEXT,
> ( 6 bytes, 2 instructions )
> ok
My disambiguifiers fix this problem:
: if state @ 0= abort" *** no interpretation semantics for: IF ***"
postpone if ; immediate
: my-if [ ' if ] literal execute ; immediate
: ttt ( flag -- ) my-if ." true" else ." false" then ;
1 ttt true
0 ttt false
You are twisting my words 180 degrees when you claim that I was trying to execute the xt of IF in interpretation mode --- you are a liar!
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-10-02 01:52 -0700 |
| Message-ID | <6bba1447-e1fe-42dd-8972-8f3c9837ad5c@googlegroups.com> |
| In reply to | #42306 |
On Friday, 2 October 2015 05:30:24 UTC+1, Rod Pemberton wrote: I.e., his apparent claim that ANS code is > non-portable would seem to be valid in the sense that the code would > break on pre-ANS Forths. Although, I don't think he mentioned pre-ANS > Forths anywhere in his claims. > I think it's worse than that. We're in a situation where "ANS Compliant" code runs differently on different *ANS compliant* systems. That's untenable in my view. Though, in defence of the people that have worked on the standards process over the years, it should be pointed out that the situation is no better in the C or C++ worlds, and I'm sure there are issues with other standardised languages too. One exception seems to ADA as far as I can see. The specification for ADA is very tight.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-10-02 08:36 -1000 |
| Message-ID | <7d6dnXa4DY0kU5PLnZ2dnUU7-LudnZ2d@supernews.com> |
| In reply to | #42311 |
On 10/1/15 10:52 PM, Mark Wills wrote: > On Friday, 2 October 2015 05:30:24 UTC+1, Rod Pemberton wrote: > I.e., his apparent claim that ANS code is >> non-portable would seem to be valid in the sense that the code would >> break on pre-ANS Forths. Although, I don't think he mentioned pre-ANS >> Forths anywhere in his claims. >> > > I think it's worse than that. We're in a situation where "ANS Compliant" > code runs differently on different *ANS compliant* systems. That's > untenable in my view. Though, in defence of the people that have worked > on the standards process over the years, it should be pointed out that > the situation is no better in the C or C++ worlds, and I'm sure there > are issues with other standardised languages too. One exception seems > to ADA as far as I can see. The specification for ADA is very tight. > Can you give some examples? Bear in mind that there are several documented options (documented in Section 4.1) that the system must describe, and an application must observe; the concept is that large or complex applications that have environmental dependencies may need a prologue to adapt to systems with environmental constraints or documented choices. Aside from ADA (which, according to the last figures I saw is significantly lower in usage than Forth), most language standards have a list of environmental options. I don't think it's reasonable to expect that an application of any complexity can be free of some dependencies (on processor, host OS, other things). If there are issues other than those documented in Section 4.1, they should be called to the attention of the Forth 200x group. 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-10-02 17:00 -0400 |
| Message-ID | <mumr5m$gti$1@dont-email.me> |
| In reply to | #42311 |
On 10/2/2015 4:52 AM, Mark Wills wrote: > On Friday, 2 October 2015 05:30:24 UTC+1, Rod Pemberton wrote: > I.e., his apparent claim that ANS code is >> non-portable would seem to be valid in the sense that the code would >> break on pre-ANS Forths. Although, I don't think he mentioned pre-ANS >> Forths anywhere in his claims. >> > > I think it's worse than that. We're in a situation where "ANS Compliant" > code runs differently on different *ANS compliant* systems. That's > untenable in my view. No, "ANS Uncompliant" code runs differently on different systems. If you are doing an operation that the spec says produces "ambiguous" conditions, by definition this code is not compliant. > Though, in defence of the people that have worked > on the standards process over the years, it should be pointed out that > the situation is no better in the C or C++ worlds, and I'm sure there > are issues with other standardised languages too. One exception seems > to ADA as far as I can see. The specification for ADA is very tight. Yea for ADA! -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-10-02 14:46 -0700 |
| Message-ID | <f57efe82-35b9-41c5-a8a7-19190c3424d6@googlegroups.com> |
| In reply to | #42320 |
On Friday, October 2, 2015 at 5:00:32 PM UTC-4, rickman wrote: > On 10/2/2015 4:52 AM, Mark Wills wrote: > > I think it's worse than that. We're in a situation where "ANS Compliant" > > code runs differently on different *ANS compliant* systems. That's > > untenable in my view. > > No, "ANS Uncompliant" code runs differently on different systems. If > you are doing an operation that the spec says produces "ambiguous" > conditions, by definition this code is not compliant. > -- > > Rick If a spec says the resulting condition in a use case is ambiguous, to me, that means that it is not known what the resulting condition will be. Are you saying that if my implementation of that use case results in a condition I can predict, then my implementation is not compliant? If so, then I'm not sure I WANT my implementation to be compliant. In order for an implementation to be non-compliant, the spec has to be clear about the resulting condition, so it can be tested against implementations to see if they produce that condition or not. How can you test for ambiguity? Therefore, if a spec says a condition is ambiguous, then every implementation complies. On the other hand, if it is merely saying that, should 3rd party use of that feature encounter such a situation, it cannot depend on a specific resulting condition, then I understand the intent. Of course, that makes it hard on 3rd party developers, because then they need to ensure that use case doesn't ever happen, which increases the likelihood of a decision to not use that feature at all.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-10-02 18:10 -0400 |
| Message-ID | <mumv9n$3is$1@dont-email.me> |
| In reply to | #42322 |
On 10/2/2015 5:46 PM, Chris Curl wrote: > On Friday, October 2, 2015 at 5:00:32 PM UTC-4, rickman wrote: >> On 10/2/2015 4:52 AM, Mark Wills wrote: >>> I think it's worse than that. We're in a situation where "ANS Compliant" >>> code runs differently on different *ANS compliant* systems. That's >>> untenable in my view. >> >> No, "ANS Uncompliant" code runs differently on different systems. If >> you are doing an operation that the spec says produces "ambiguous" >> conditions, by definition this code is not compliant. >> -- >> >> Rick > > If a spec says the resulting condition in a use case is ambiguous, to me, that means that it is not known what the resulting condition will be. Not "not known"... not specified. Any given system may produce a known and repeatable result, but that result may be different from other systems or the same system under other conditions. > Are you saying that if my implementation of that use case results in a condition I can predict, then my implementation is not compliant? If so, then I'm not sure I WANT my implementation to be compliant. No one in their right mind is saying that. > In order for an implementation to be non-compliant, the spec has to be clear about the resulting condition, so it can be tested against implementations to see if they produce that condition or not. How can you test for ambiguity? Therefore, if a spec says a condition is ambiguous, then every implementation complies. You have crossed the boarder into loony land. When the spec says a usage produces an "ambiguous condition" it gives a long list of potential responses by the system including, "take implementation-dependent actions". Obviously this does not need to be tested. That is the point of an "ambiguous condition", it is outside of what is specified by the spec. > On the other hand, if it is merely saying that, should 3rd party use of that feature encounter such a situation, it cannot depend on a specific resulting condition, then I understand the intent. Of course, that makes it hard on 3rd party developers, because then they need to ensure that use case doesn't ever happen, which increases the likelihood of a decision to not use that feature at all. Wow, I can't tell if you really don't get it or if you are being intentionally difficult. Yes, if the spec says a "use case" results in an ambiguous condition that means it is *not* specified in the spec and *may* differ between systems. For a program to be compliant to the spec and produce consistent results across platforms, it should not use "features" that create ambiguous conditions. Everything about different systems can't be specified to always be the same. If it were, they would not be able to work on different platforms or support different capabilities. Other things are considered to be "ambiguous conditions" because doing them doesn't make a lot of sense and is not worth the effort of making them work one particular way. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-10-02 16:08 -0700 |
| Message-ID | <877fn4amxg.fsf@jester.gateway.sonic.net> |
| In reply to | #42322 |
Chris Curl <ccurl609@gmail.com> writes: > Are you saying that if my implementation of that use case results in a > condition I can predict, then my implementation is not compliant? Of course not. It means that if all you know about someone else's implementation is that it's compliant, you can't predict what will happen on ambiguous conditions. They (and you) can of course implement something predictable and maybe even document it. > Therefore, if a spec says a condition is ambiguous, then every > implementation complies. Correct. > On the other hand, if it is merely saying that, should 3rd party use > of that feature encounter such a situation, it cannot depend on a > specific resulting condition, Yes. Think of a subscript error in a C program. The C standard says what happens when a subscript is in range, but says nothing about what's supposed to happen when it's out of range. Traditionally in C, that's an unsafe operation and anything can happen. By contrast, in (say) Python, or with the .at() operation in a C++ STL container, subscript errors are supposed to raise an exception. Ambiguous condition is an error which the standard doesn't tell you how (or whether) to handle. One thing to keep in mind about Forth is that many aspects of its design and standard are aimed at very memory-constrained or deep-embedded processors, where the implementations are simply not willing to spend any resources on niceties like aborting on FIND failing (or stack underflow etc). You can use those systems interactively but it's pretty easy to hang the interpreter on some of them, at which point you hit reset. Systems on PC's usually have more amenities such as better error signalling.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-10-02 20:44 -0400 |
| Message-ID | <op.x5wm0zbjyfako5@localhost> |
| In reply to | #42324 |
On Fri, 02 Oct 2015 19:08:27 -0400, Paul Rubin <no.email@nospam.invalid> wrote: > Yes. Think of a subscript error in a C program. The C standard says > what happens when a subscript is in range, but says nothing about what's > supposed to happen when it's out of range. Traditionally in C, that's > an unsafe operation and anything can happen. (nitpick ...) It defines access one past the end of certain arrays as valid, e.g., to detect nul '\0' at the end of string. But, yes, in general, access outside the scope of valid C objects is undefined or implementation defined. Rod Pemberton -- Just how many texting and calendar apps does humanity need? Just how many food articles from neurotic millenials do we need?
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2015-10-31 06:54 -0400 |
| Message-ID | <1d793bd7rhaq6vblplj5da2jaukilaire2@4ax.com> |
| In reply to | #42326 |
On Fri, 02 Oct 2015 20:44:49 -0400, "Rod Pemberton" <boo@fasdfrewar.cdm> wrote: > On Fri, 02 Oct 2015 19:08:27 -0400, Paul Rubin <no.email@nospam.invalid> wrote: > > > Yes. Think of a subscript error in a C program. The C standard says > > what happens when a subscript is in range, but says nothing about what's > > supposed to happen when it's out of range. Traditionally in C, that's > > an unsafe operation and anything can happen. > > (nitpick ...) > > It defines access one past the end of certain arrays as valid, > e.g., to detect nul '\0' at the end of string. But, yes, in > general, access outside the scope of valid C objects is > undefined or implementation defined. > People often treat the \0 as "after" the string, although the C standards define the term string to include the (first) \0 and then repeatedly talk about strings, characters, and character sequences "including the terminating null" or "not including ...". However, everyone agrees the \0 is in the *array* that the string is stored in. See for example the only strings defined by the core language as opposed to the standard library, in 6.4.5p6: "a byte or code of value zero is appended to each multibyte character sequence that results from a string literal or literals. [footnote omitted] The multibyte character sequence is then used to initialize an array of static storage duration and length just sufficient to contain the sequence." i.e. the char sequence in the array includes the added null. C also allows calculating the address of, but *not* accessing, the fictional element that would be just after the array &a[n] or a+n . This means (on most implementations) an array can't be allocated exactly at the end of the address space, or the end of a segment when real segments are used, which the compiler can usually avoid easily.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <too@zxcvfeqad.cdm> |
|---|---|
| Date | 2015-11-02 02:34 -0500 |
| Message-ID | <op.x7gpzwkqsi10q1@localhost> |
| In reply to | #43032 |
On Sat, 31 Oct 2015 06:54:26 -0400, David Thompson <dave.thompson2@verizon.net> wrote: > On Fri, 02 Oct 2015 20:44:49 -0400, "Rod Pemberton" > <boo@fasdfrewar.cdm> wrote: >> On Fri, 02 Oct 2015 19:08:27 -0400, Paul Rubin <no.email@nospam.invalid> wrote: >> >> > Yes. Think of a subscript error in a C program. The C standard says >> > what happens when a subscript is in range, but says nothing about what's >> > supposed to happen when it's out of range. Traditionally in C, that's >> > an unsafe operation and anything can happen. >> >> (nitpick ...) >> >> It defines access one past the end of certain arrays as valid, >> e.g., to detect nul '\0' at the end of string. But, yes, in >> general, access outside the scope of valid C objects is >> undefined or implementation defined. >> > People often treat the \0 as "after" the string, although the C > standards define the term string to include the (first) \0 and then > repeatedly talk about strings, characters, and character sequences > "including the terminating null" or "not including ...". > s/null/nul/ NUL is a character for ASCII and EBCDIC. C redefines the NUL character to be as large as the size of the C byte which can be larger in bits than the size of a C character. This was to allow for finding 16-bit NULs quickly on word sized machines when the character size is 8-bits or 9-bits, etc. > However, everyone agrees the \0 is in the *array* that the string is > stored in. [...] Yes. It's referred to as "after" the string because of the declared length of the string does not include the NUL character. > C also allows calculating the address of, but *not* accessing, the > fictional element that would be just after the array &a[n] or a+n . I know of no bounds checks or range checks for C that would prohibit accessing anything at any address. Accessing anything outside the scope of a valid C object is "undefined behavior" or implementation defined behavior, such as for a pointer to a memory mapped device. In fact, the ability to access just prior to an "array" or just after the end of an array is used by malloc() on many implementations since malloc() typically creates a header struct just prior to the allocated memory. > This means (on most implementations) an array can't be allocated > exactly at the end of the address space, or the end of a segment when > real segments are used, which the compiler can usually avoid easily. Here, I think you may be refering to a C object larger than a C byte in size crossing a segment boundary, perhaps causing a access violation such as a page fault, etc. This has nothing to do with C, but entirely with the platform. Rod Pemberton -- When El Chapo is the most beloved man in Mexico and Trump is the most hated, it shows that Mexico is truly fouled up.
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2015-12-22 06:45 -0500 |
| Message-ID | <jvdi7b1iqnbvu52vlg6h275m6i1o8kedpj@4ax.com> |
| In reply to | #43083 |
On Mon, 02 Nov 2015 02:34:34 -0500, "Rod Pemberton"
<too@zxcvfeqad.cdm> wrote:
> On Sat, 31 Oct 2015 06:54:26 -0400, David Thompson <dave.thompson2@verizon.net> wrote:
> > On Fri, 02 Oct 2015 20:44:49 -0400, "Rod Pemberton"
> > <boo@fasdfrewar.cdm> wrote:
>
> >> On Fri, 02 Oct 2015 19:08:27 -0400, Paul Rubin <no.email@nospam.invalid> wrote:
> >>
> >> > Yes. Think of a subscript error in a C program. The C standard says
> >> > what happens when a subscript is in range, but says nothing about what's
> >> > supposed to happen when it's out of range. Traditionally in C, that's
> >> > an unsafe operation and anything can happen.
> >>
> >> (nitpick ...)
> >>
> >> It defines access one past the end of certain arrays as valid,
> >> e.g., to detect nul '\0' at the end of string. But, yes, in
> >> general, access outside the scope of valid C objects is
> >> undefined or implementation defined.
> >>
> > People often treat the \0 as "after" the string, although the C
> > standards define the term string to include the (first) \0 and then
> > repeatedly talk about strings, characters, and character sequences
> > "including the terminating null" or "not including ...".
> >
>
> s/null/nul/
>
> NUL is a character for ASCII and EBCDIC. C redefines the NUL character
> to be as large as the size of the C byte which can be larger in bits
> than the size of a C character. This was to allow for finding 16-bit
> NULs quickly on word sized machines when the character size is 8-bits
> or 9-bits, etc.
>
Yes, NUL is a character in ASCII and EBCDIC. C intentionally doesn't
_require_ either of those, even though (all) implementations do, and
uses the abstract name 'null character' spelled as I have it.
> > However, everyone agrees the \0 is in the *array* that the string is
> > stored in. [...]
>
> Yes.
>
> It's referred to as "after" the string because of the declared length
> of the string does not include the NUL character.
>
You can't declare a string. You can and usually do declare an array
that contains a string, and the declared size _does_ include the \0,
otherwise the \0 may not exist and it isn't a string. strlen() counts
the (current, possibly changed) length not including the \0, and is
(very!) widely used, but is not a declaration.
> > C also allows calculating the address of, but *not* accessing, the
> > fictional element that would be just after the array &a[n] or a+n .
>
> I know of no bounds checks or range checks for C that would prohibit
> accessing anything at any address. Accessing anything outside the
> scope of a valid C object is "undefined behavior" or implementation
> defined behavior, such as for a pointer to a memory mapped device.
> In fact, the ability to access just prior to an "array" or just after
> the end of an array is used by malloc() on many implementations since
> malloc() typically creates a header struct just prior to the allocated
> memory.
>
_Accessing_ anything outside of a valid object is UB, but _computing
the address_ just after the last element of an array, or just after a
scalar treated as an array of one element, _is_ standard and portable.
This is done specifically to allow common idioms like
for ( p = &a[0]; p < &a[n]; p++ ) do_something_with (*p);
/* &a[0] is exactly equivalent to and often simplified as a,
but I keep the full form here for clarity */
See 6.5.6p8 of n1570 at http://www.open-std.org/jtc1/sc22/wg14/
(the FCD for C11) or n869 (the last public draft of C99); C89/90 were
the same but are not available online that I have found.
Note the reverse, scanning downward to &a[-1], is NOT standard and not
guaranteed, although many many implementations do allow it.
malloc() is part of the implementation and can 'look under the cover'.
> > This means (on most implementations) an array can't be allocated
> > exactly at the end of the address space, or the end of a segment when
> > real segments are used, which the compiler can usually avoid easily.
>
> Here, I think you may be refering to a C object larger than a C byte
> in size crossing a segment boundary, perhaps causing a access violation
> such as a page fault, etc. This has nothing to do with C, but entirely
> with the platform.
>
Not even crossing; if a C object ends just at the end of the segment
or space, and as a result &a[n] compares equal to 0 and/or causes an
error, that's nonconforming. All systems I've seen already have
special things at the top of the address space (and usually the bottom
too, making it easy to use 0 for the null pointer), and when segments
are used (which is rare) wasting _maybe_ one byte at the top is not a
problem -- but it is a requirement that must not be forgotten.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <too@zxcvfeqad.cdm> |
|---|---|
| Date | 2015-11-02 02:34 -0500 |
| Message-ID | <op.x7gpzyo0si10q1@localhost> |
| In reply to | #43032 |
On Sat, 31 Oct 2015 06:54:26 -0400, David Thompson <dave.thompson2@verizon.net> wrote: > On Fri, 02 Oct 2015 20:44:49 -0400, "Rod Pemberton" > <boo@fasdfrewar.cdm> wrote: >> On Fri, 02 Oct 2015 19:08:27 -0400, Paul Rubin <no.email@nospam.invalid> wrote: >> >> > Yes. Think of a subscript error in a C program. The C standard says >> > what happens when a subscript is in range, but says nothing about what's >> > supposed to happen when it's out of range. Traditionally in C, that's >> > an unsafe operation and anything can happen. >> >> (nitpick ...) >> >> It defines access one past the end of certain arrays as valid, >> e.g., to detect nul '\0' at the end of string. But, yes, in >> general, access outside the scope of valid C objects is >> undefined or implementation defined. >> > People often treat the \0 as "after" the string, although the C > standards define the term string to include the (first) \0 and then > repeatedly talk about strings, characters, and character sequences > "including the terminating null" or "not including ...". > s/null/nul/ NUL is a character for ASCII and EBCDIC. C redefines the NUL character to be as large as the size of the C byte which can be larger in bits than the size of a C character. This was to allow for finding 16-bit NULs quickly on word sized machines when the character size is 8-bits or 9-bits, etc. > However, everyone agrees the \0 is in the *array* that the string is > stored in. [...] Yes. It's referred to as "after" the string because of the declared length of the string does not include the NUL character. > C also allows calculating the address of, but *not* accessing, the > fictional element that would be just after the array &a[n] or a+n . I know of no bounds checks or range checks for C that would prohibit accessing anything at any address. Accessing anything outside the scope of a valid C object is "undefined behavior" or implementation defined behavior, such as for a pointer to a memory mapped device. In fact, the ability to access just prior to an "array" or just after the end of an array is used by malloc() on many implementations since malloc() typically creates a header struct just prior to the allocated memory. > This means (on most implementations) an array can't be allocated > exactly at the end of the address space, or the end of a segment when > real segments are used, which the compiler can usually avoid easily. Here, I think you may be refering to a C object larger than a C byte in size crossing a segment boundary, perhaps causing a access violation such as a page fault, etc. This has nothing to do with C, but entirely with the platform. Rod Pemberton -- When El Chapo is the most beloved man in Mexico and Trump is the most hated, it shows that Mexico is truly fouled up.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-10-02 15:16 -1000 |
| Message-ID | <Nt-dnbJvoerysZLLnZ2dnUU7-f2dnZ2d@supernews.com> |
| In reply to | #42324 |
On 10/2/15 1:08 PM, Paul Rubin wrote: > Chris Curl <ccurl609@gmail.com> writes: >> Are you saying that if my implementation of that use case results in a >> condition I can predict, then my implementation is not compliant? > > Of course not. It means that if all you know about someone else's > implementation is that it's compliant, you can't predict what will > happen on ambiguous conditions. They (and you) can of course implement > something predictable and maybe even document it. Not "maybe". A compliant system *must* document its response to the ambiguous conditions called out in the standard: 4.1.2 Ambiguous conditions A system *shall* document the system action taken upon each of the general or specific ambiguous conditions identified in this standard. See 3.4.4 Possible actions on an ambiguous condition. >> Therefore, if a spec says a condition is ambiguous, then every >> implementation complies. > > Correct. ...providing the response is documented. Of course, it's possible to document that the response consists of a particular THROW if the Exception Word Set is being used. That's an opportunity for your application to do a CATCH and control the response yourself. If you don't do that, you'll get whatever action the system provides at the top level where otherwise un-handled exceptions are handled (e.g., with an abort), and that handling should also be documented. A set of THROW codes for each of the ambiguous conditions listed in the standard is included in the Standard's section on the Exception Word Set. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-10-02 18:21 -0700 |
| Message-ID | <8737xsags2.fsf@jester.gateway.sonic.net> |
| In reply to | #42327 |
"Elizabeth D. Rather" <erather@forth.com> writes: > A system *shall* document the system action taken upon each of the > general or specific ambiguous conditions Oh cool! I wonder how many actually do that.
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web