Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #9205 > unrolled thread

bug report Bernd Paysan's bigForth v231 v240

Back to article view | Back to comp.lang.forth

Contents

  bug report Bernd Paysan's bigForth v231 v240 "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-24 18:26 -0500
    Re: bug report Bernd Paysan's bigForth v231 v240 Brad <hwfwguy@gmail.com> - 2012-01-24 16:06 -0800
      Re: bug report Bernd Paysan's bigForth v231 v240 David Kuehling <dvdkhlng@gmx.de> - 2012-01-25 11:03 +0100
      Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-25 04:31 -0800
        Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-25 08:00 -1000
          Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-25 10:04 -0800
    Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-24 14:06 -1000
      Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-25 04:40 -0800
        Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-25 04:42 -0800
        Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-25 08:02 -1000
        Re: bug report Bernd Paysan's bigForth v231 v240 Coos Haak <chforth@hccnet.nl> - 2012-01-25 19:45 +0100
      Re: bug report Bernd Paysan's bigForth v231 v240 "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-25 11:00 -0500
        Re: bug report Bernd Paysan's bigForth v231 v240 Coos Haak <chforth@hccnet.nl> - 2012-01-25 19:40 +0100
          Re: bug report Bernd Paysan's bigForth v231 v240 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-26 15:37 +0000
            Re: bug report Bernd Paysan's bigForth v231 v240 Coos Haak <chforth@hccnet.nl> - 2012-01-26 22:53 +0100
        Re: bug report Bernd Paysan's bigForth v231 v240 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-25 17:50 +0000
    Re: bug report Bernd Paysan's bigForth v231 v240 "Peter Knaggs" <pjk@bcs.org.uk> - 2012-01-25 00:27 +0000
    Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-25 04:29 -0800
      Re: bug report Bernd Paysan's bigForth v231 v240 "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-25 11:01 -0500
        Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-25 07:51 -1000
    Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-25 04:43 -0800
      Re: bug report Bernd Paysan's bigForth v231 v240 "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-25 11:02 -0500
        Re: bug report Bernd Paysan's bigForth v231 v240 Doug Hoffman <glidedog@gmail.com> - 2012-01-25 11:27 -0500
        Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-25 08:38 -0800
          Re: bug report Bernd Paysan's bigForth v231 v240 Arnold Doray <invalid@invalid.com> - 2012-01-26 00:54 +0000
            Re: bug report Bernd Paysan's bigForth v231 v240 Coos Haak <chforth@hccnet.nl> - 2012-01-26 22:58 +0100
              Re: bug report Bernd Paysan's bigForth v231 v240 Arnold Doray <invalid@invalid.com> - 2012-01-27 04:15 +0000
                Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-27 02:29 -0800
                  Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-27 02:44 -0800
                    Re: bug report Bernd Paysan's bigForth v231 v240 Arnold Doray <invalid@invalid.com> - 2012-01-27 14:38 +0000
                      Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-27 08:06 -0800
                      Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-27 08:08 -0800
                  Re: bug report Bernd Paysan's bigForth v231 v240 Arnold Doray <invalid@invalid.com> - 2012-01-27 15:30 +0000
                    Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-27 08:06 -1000
          Re: bug report Bernd Paysan's bigForth v231 v240 "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-27 20:21 -0500
            Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-27 16:19 -1000
              Re: bug report Bernd Paysan's bigForth v231 v240 "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-28 14:18 -0500
                Re: bug report Bernd Paysan's bigForth v231 v240 Alex McDonald <blog@rivadpm.com> - 2012-01-28 12:30 -0800
                Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-28 13:42 -0800
                  Re: bug report Bernd Paysan's bigForth v231 v240 Brad <hwfwguy@gmail.com> - 2012-01-28 17:37 -0800
                    Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-29 00:31 -0800
                      Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-29 07:19 -1000
                      Re: bug report Bernd Paysan's bigForth v231 v240 BruceMcF <agila61@netscape.net> - 2012-01-29 15:36 -0800
                        Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-30 03:46 -0800
                          Re: bug report Bernd Paysan's bigForth v231 v240 "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-12 18:01 -0500
                Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-28 13:38 -1000
                Re: bug report Bernd Paysan's bigForth v231 v240 BruceMcF <agila61@netscape.net> - 2012-01-28 19:58 -0800
                  Re: bug report Bernd Paysan's bigForth v231 v240 kenney@cix.compulink.co.uk - 2012-01-29 05:04 -0600
                    Re: bug report Bernd Paysan's bigForth v231 v240 John Passaniti <john.passaniti@gmail.com> - 2012-01-29 10:58 -0800
                    Re: bug report Bernd Paysan's bigForth v231 v240 BruceMcF <agila61@netscape.net> - 2012-01-29 16:04 -0800
                Re: bug report Bernd Paysan's bigForth v231 v240 Arnold Doray <invalid@invalid.com> - 2012-01-29 09:18 +0000
                  Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-29 07:23 -1000
              Re: bug report Bernd Paysan's bigForth v231 v240 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-30 14:20 +0000
                Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-30 06:51 -0800
                  Re: bug report Bernd Paysan's bigForth v231 v240 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-30 15:08 +0000
                Re: bug report Bernd Paysan's bigForth v231 v240 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-30 09:10 -0600
            Re: bug report Bernd Paysan's bigForth v231 v240 BruceMcF <agila61@netscape.net> - 2012-01-27 19:02 -0800
            Re: bug report Bernd Paysan's bigForth v231 v240 Brad <hwfwguy@gmail.com> - 2012-01-28 09:32 -0800
        Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-25 08:42 -0800
        Re: bug report Bernd Paysan's bigForth v231 v240 BruceMcF <agila61@netscape.net> - 2012-01-25 09:33 -0800
        Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-25 07:55 -1000
        Re: bug report Bernd Paysan's bigForth v231 v240 Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-01-25 22:17 +0000
    Re: bug report Bernd Paysan's bigForth v231 v240 BruceMcF <agila61@netscape.net> - 2012-01-25 07:30 -0800
    Re: bug report Bernd Paysan's bigForth v231 v240 Bernd Paysan <bernd.paysan@gmx.de> - 2012-02-07 17:12 +0100

Page 1 of 4  [1] 2 3 4  Next page →

#9205 — bug report Bernd Paysan's bigForth v231 v240

Bernd Paysan,

I know you're not fond of my statements, but I'm probably helping you out
with this bug report.  Are you aware of the following issue?

I noticed an interesting bug with your ANS bigForth v2.3.1 and v2.4.0.
bigForth is overwriting data in some words.  Apparently, it's writing parsed
data to DP or HERE, like the fig-Forth code does.  However, the DP
dictionary-pointer or HERE is not being adjusted via an ALLOT.


These are two of my test sequences which work for GForth and Win32Forth:

CREATE GRAPES 1 , GRAPES @ .

CREATE ORANGES 1 ORANGES ! ORANGES @ .


The GRAPES example works because DP is adjusted via the , COMMA.

CREATE GRAPES
1 ,
GRAPES @ .


The ORANGE example fails because DP isn't moved after storing the number.
The number is being overwritten with parsed data.

CREATE ORANGES
1 ORANGES !
ORANGES @ .


If one ALLOTS, replacing ORANGE with PEARS to prevent a name collision, then
the second sequence works.

CREATE PEARS
1 PEARS 1 CELLS ALLOT !
PEARS @ .


How do I know all this?  My fig-Forth based interpreter is doing the exactly
same thing ...  The adjustment via ALLOT is the same too.  Apparently, there
is a difference in where some Forths copy their parsed data.  fig-Forth code
copies straight to DP or HERE.  Unfortunately, the one fig-Forth for DOS I
tested had some other failure recognizing CREATE words.  I'll attempt to
test on another fig-Forth to see if fig-Forth actually has the issue.  I may
not report the results here though ...

At least you now know what the issue is and can fix it ...


Rod Pemberton

[toc] | [next] | [standalone]

#9209

On Jan 24, 4:26 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> The ORANGE example fails because DP isn't moved after storing the number.
> The number is being overwritten with parsed data.
>
> CREATE ORANGES
> 1 ORANGES !
> ORANGES @ .
>
What I get from this is: Don't trust memory beyond HERE, or any
unallocated memory. It can get clobbered any number of different ways.

CREATE ORANGES creates a data structure zero bytes long. Why should it
be safe to write to?

-Brad

[toc] | [prev] | [next] | [standalone]

#9213

>>>>> "Brad" == Brad  <hwfwguy@gmail.com> writes:

> On Jan 24, 4:26 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
>> The ORANGE example fails because DP isn't moved after storing the
>> number.  The number is being overwritten with parsed data.
>> 
>> CREATE ORANGES 1 ORANGES !  ORANGES @ .
>> 
> What I get from this is: Don't trust memory beyond HERE, or any
> unallocated memory. It can get clobbered any number of different ways.

> CREATE ORANGES creates a data structure zero bytes long. Why should it
> be safe to write to?

AFAIR the standard allows to use the memory at HERE, even without
ALLOTing it.  You only have to keep in mind, that it might be shared
with PAD, the text interpreter (input buffer), the number output
conversion (. <# # etc.), and any defining words.

david
-- 
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40

[toc] | [prev] | [next] | [standalone]

#9216

On Jan 25, 12:06 am, Brad <hwfw...@gmail.com> wrote:
> On Jan 24, 4:26 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:> The ORANGE example fails because DP isn't moved after storing the number.
> > The number is being overwritten with parsed data.
>
> > CREATE ORANGES
> > 1 ORANGES !
> > ORANGES @ .
>
> What I get from this is: Don't trust memory beyond HERE, or any
> unallocated memory. It can get clobbered any number of different ways.
>
> CREATE ORANGES creates a data structure zero bytes long. Why should it
> be safe to write to?
>
> -Brad

No it doesn't. It creates a word in the dictionary such that, when the
word is executed, it returns the address of a single cell allocated
for data storage. In old FIG/ITC parlence one would call that cell the
PFA (parameter field address) though that term isn't directly relevant
in more modern compilers, as I understand it.

[toc] | [prev] | [next] | [standalone]

#9232

On 1/25/12 2:31 AM, Mark Wills wrote:
> On Jan 25, 12:06 am, Brad<hwfw...@gmail.com>  wrote:
>> On Jan 24, 4:26 pm, "Rod Pemberton"<do_not_h...@noavailemail.cmm>
>> wrote:>  The ORANGE example fails because DP isn't moved after storing the number.
>>> The number is being overwritten with parsed data.
>>
>>> CREATE ORANGES
>>> 1 ORANGES !
>>> ORANGES @ .
>>
>> What I get from this is: Don't trust memory beyond HERE, or any
>> unallocated memory. It can get clobbered any number of different ways.
>>
>> CREATE ORANGES creates a data structure zero bytes long. Why should it
>> be safe to write to?
>>
>> -Brad
>
> No it doesn't. It creates a word in the dictionary such that, when the
> word is executed, it returns the address of a single cell allocated
> for data storage. In old FIG/ITC parlence one would call that cell the
> PFA (parameter field address) though that term isn't directly relevant
> in more modern compilers, as I understand it.

Wrong. CREATE defines a word that will return the address of the next 
location. It doesn't *allocate* any space at that location. The reason 
is that the user can then allocate as much space as desired, in any 
number of different ways. But until data space is actually allocated, 
none has been reserved, and there is no protection for that space.

Cheers,
Ellizabeth

-- 
==================================================
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]

#9234

On Jan 25, 6:00 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> On 1/25/12 2:31 AM, Mark Wills wrote:
>
>
>
>
>
> > On Jan 25, 12:06 am, Brad<hwfw...@gmail.com>  wrote:
> >> On Jan 24, 4:26 pm, "Rod Pemberton"<do_not_h...@noavailemail.cmm>
> >> wrote:>  The ORANGE example fails because DP isn't moved after storing the number.
> >>> The number is being overwritten with parsed data.
>
> >>> CREATE ORANGES
> >>> 1 ORANGES !
> >>> ORANGES @ .
>
> >> What I get from this is: Don't trust memory beyond HERE, or any
> >> unallocated memory. It can get clobbered any number of different ways.
>
> >> CREATE ORANGES creates a data structure zero bytes long. Why should it
> >> be safe to write to?
>
> >> -Brad
>
> > No it doesn't. It creates a word in the dictionary such that, when the
> > word is executed, it returns the address of a single cell allocated
> > for data storage. In old FIG/ITC parlence one would call that cell the
> > PFA (parameter field address) though that term isn't directly relevant
> > in more modern compilers, as I understand it.
>
> Wrong. CREATE defines a word that will return the address of the next
> location. It doesn't *allocate* any space at that location. The reason
> is that the user can then allocate as much space as desired, in any
> number of different ways. But until data space is actually allocated,
> none has been reserved, and there is no protection for that space.
>
> Cheers,
> Ellizabeth
>
> --
> ==================================================
> Elizabeth D. Rather   (US & Canada)   800-55-FORTH
> FORTH Inc.                         +1 310.999.6784
> 5959 West Century Blvd. Suite 700
> Los Angeles, CA 90045http://www.forth.com
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

Indeed. Much better wording. Thank-you.

Mark

[toc] | [prev] | [next] | [standalone]

#9210

On 1/24/12 1:26 PM, Rod Pemberton wrote:
> Bernd Paysan,
>
> I know you're not fond of my statements, but I'm probably helping you out
> with this bug report.  Are you aware of the following issue?
>
> I noticed an interesting bug with your ANS bigForth v2.3.1 and v2.4.0.
> bigForth is overwriting data in some words.  Apparently, it's writing parsed
> data to DP or HERE, like the fig-Forth code does.  However, the DP
> dictionary-pointer or HERE is not being adjusted via an ALLOT.
>
>
> These are two of my test sequences which work for GForth and Win32Forth:
>
> CREATE GRAPES 1 , GRAPES @ .
>
> CREATE ORANGES 1 ORANGES ! ORANGES @ .

It might coincidentally work, but it certainly isn't guaranteed to, 
since you're storing into space that hasn't been ALLOTted.

> The GRAPES example works because DP is adjusted via the , COMMA.
>
> CREATE GRAPES
> 1 ,
> GRAPES @ .
>
>
> The ORANGE example fails because DP isn't moved after storing the number.
> The number is being overwritten with parsed data.

DP isn't supposed to be affected by ! in any way.  If it were, that 
would be a bug.

> CREATE ORANGES
> 1 ORANGES !
> ORANGES @ .
>
>
> If one ALLOTS, replacing ORANGE with PEARS to prevent a name collision, then
> the second sequence works.
>
> CREATE PEARS
> 1 PEARS 1 CELLS ALLOT !
> PEARS @ .

That is correct (though clumsy) usage. Properly speaking, one should do 
the ALLOT right after the CREATE in order to properly reserve the space.

> How do I know all this?  My fig-Forth based interpreter is doing the exactly
> same thing ...  The adjustment via ALLOT is the same too.  Apparently, there
> is a difference in where some Forths copy their parsed data.  fig-Forth code
> copies straight to DP or HERE.  Unfortunately, the one fig-Forth for DOS I
> tested had some other failure recognizing CREATE words.  I'll attempt to
> test on another fig-Forth to see if fig-Forth actually has the issue.  I may
> not report the results here though ...
>
> At least you now know what the issue is and can fix it ...

There is nothing to fix. Bigforth is working as it should.

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]

#9218

>
> That is correct (though clumsy) usage. Properly speaking, one should do
> the ALLOT right after the CREATE in order to properly reserve the space.
>

Ah... Yes. That's interesting. I should have tested more throughly
before posting.

On my system:

CREATE FRED
: TEST 1 2 3 ;
100 FRED !
FRED
ERROR: FRED NOT FOUND

Because the link-field of the word TEST got compiled into the 'body'
of FRED. When 100 was written to the same location, the dictionary
linkage broke.

Hmmm... I wonder if the definition of CREATE should include a 1 CELLS
ALLOT within it?

Mark

[toc] | [prev] | [next] | [standalone]

#9220

On Jan 25, 12:40 pm, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> > That is correct (though clumsy) usage. Properly speaking, one should do
> > the ALLOT right after the CREATE in order to properly reserve the space.
>
> Ah... Yes. That's interesting. I should have tested more throughly
> before posting.
>
> On my system:
>
> CREATE FRED
> : TEST 1 2 3 ;
> 100 FRED !
> FRED
> ERROR: FRED NOT FOUND
>
> Because the link-field of the word TEST got compiled into the 'body'
> of FRED. When 100 was written to the same location, the dictionary
> linkage broke.
>
> Hmmm... I wonder if the definition of CREATE should include a 1 CELLS
> ALLOT within it?
>
> Mark

Actually, no. It shouldn't, should it? Because then lists would be
busted:

CREATE FRED 1 , 2 , 3 , 4 ,

If CREATE alloted a cell then that would make the above somewhat
awkward.

Ok. I understand what is going on now! Ignore me!

[toc] | [prev] | [next] | [standalone]

#9233

On 1/25/12 2:40 AM, Mark Wills wrote:
...
> Hmmm... I wonder if the definition of CREATE should include a 1 CELLS
> ALLOT within it?

No, because then if you said,

    CREATE STUFF 10 CELLS ALLOT

...you'd get 11 cells.  If you want one cell, you should use VARIABLE as 
your defining word.

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]

#9236

Op Wed, 25 Jan 2012 04:40:58 -0800 (PST) schreef Mark Wills:

>>
>> That is correct (though clumsy) usage. Properly speaking, one should do
>> the ALLOT right after the CREATE in order to properly reserve the space.
>>
> 
> Ah... Yes. That's interesting. I should have tested more throughly
> before posting.
> 
> On my system:
> 
> CREATE FRED
>: TEST 1 2 3 ;
> 100 FRED !
> FRED
> ERROR: FRED NOT FOUND
> 
> Because the link-field of the word TEST got compiled into the 'body'
> of FRED. When 100 was written to the same location, the dictionary
> linkage broke.
> 
> Hmmm... I wonder if the definition of CREATE should include a 1 CELLS
> ALLOT within it?
> 
Hey, you discovered a possible definition of VARIABLE!

: VARIABLE   CREATE 0 , ;

> Mark

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

[toc] | [prev] | [next] | [standalone]

#9223

"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:ifadnSBOusMN2oLSnZ2dnUVZ_uidnZ2d@supernews.com...
> On 1/24/12 1:26 PM, Rod Pemberton wrote:
> > Bernd Paysan,
> >
> > I know you're not fond of my statements, but I'm probably helping you
> > out with this bug report.  Are you aware of the following issue?
> >
> > I noticed an interesting bug with your ANS bigForth v2.3.1 and v2.4.0.
> > bigForth is overwriting data in some words.  Apparently, it's writing
> > parsed data to DP or HERE, like the fig-Forth code does.  However,
> > the DP dictionary-pointer or HERE is not being adjusted via an ALLOT.
> >
> >
> > These are two of my test sequences which work for GForth and Win32Forth:
> >
> > CREATE GRAPES 1 , GRAPES @ .
> >
> > CREATE ORANGES 1 ORANGES ! ORANGES @ .
>
> It might coincidentally work, but it certainly isn't guaranteed to,
> since you're storing into space that hasn't been ALLOTted.
>

I just tested 21 Forths.  13 work.  6 fail.  2 have other issues.  Standard
behavior seems to be to not overwrite dictionary space when parsing.

> > The GRAPES example works because DP is adjusted via the , COMMA.
> >
> > CREATE GRAPES
> > 1 ,
> > GRAPES @ .
> >
> >
> > The ORANGE example fails because DP isn't moved after storing the
> > number. The number is being overwritten with parsed data.
>
> DP isn't supposed to be affected by ! in any way.  If it were, that
> would be a bug.
>

I didn't say that DP should be adjusted.  The bigForth issue is not with the
lack of an ALLOT, COMMA, or adjustment to HERE or DP.  The issue is with
bigForth's parsing related data overwriting the user data stored in a
definition.  As you've stated, storing a value "into space that hasn't been
ALLOTted" "isn't guaranteed to" work, but does that relate to 1) just
storing the value and say a COMMA storing another value there thereby
changing the originally stored value, or 2) does that apply to something
else corrupting a definition, e.g., parsing?  The latter is what is going on
in bigForth.  Gforth and Win32Forth do not update DP either.  They don't
corrupt the stored value in the definition.  They do overwrite the initial
value with another when someone uses a COMMA, or permanently allocate the
initial value when someone uses ALLOT.

> There is nothing to fix. Bigforth is working as it should.
>

I think you misunderstood what I said.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#9235

Op Wed, 25 Jan 2012 11:00:53 -0500 schreef Rod Pemberton:

> "Elizabeth D. Rather" <erather@forth.com> wrote in message
> news:ifadnSBOusMN2oLSnZ2dnUVZ_uidnZ2d@supernews.com...
>> On 1/24/12 1:26 PM, Rod Pemberton wrote:
>>> Bernd Paysan,
>>>
>>> I know you're not fond of my statements, but I'm probably helping you
>>> out with this bug report.  Are you aware of the following issue?
>>>
>>> I noticed an interesting bug with your ANS bigForth v2.3.1 and v2.4.0.
>>> bigForth is overwriting data in some words.  Apparently, it's writing
>>> parsed data to DP or HERE, like the fig-Forth code does.  However,
>>> the DP dictionary-pointer or HERE is not being adjusted via an ALLOT.
>>>
>>>
>>> These are two of my test sequences which work for GForth and Win32Forth:
>>>
>>> CREATE GRAPES 1 , GRAPES @ .
>>>
>>> CREATE ORANGES 1 ORANGES ! ORANGES @ .
>>
>> It might coincidentally work, but it certainly isn't guaranteed to,
>> since you're storing into space that hasn't been ALLOTted.
>>
> 
> I just tested 21 Forths.  13 work.  6 fail.  2 have other issues.  Standard
> behavior seems to be to not overwrite dictionary space when parsing.
> 
>>> The GRAPES example works because DP is adjusted via the , COMMA.
>>>
>>> CREATE GRAPES
>>> 1 ,
>>> GRAPES @ .
>>>
>>>
>>> The ORANGE example fails because DP isn't moved after storing the
>>> number. The number is being overwritten with parsed data.
>>
>> DP isn't supposed to be affected by ! in any way.  If it were, that
>> would be a bug.
>>
> 
> I didn't say that DP should be adjusted.  The bigForth issue is not with the
> lack of an ALLOT, COMMA, or adjustment to HERE or DP.  The issue is with
> bigForth's parsing related data overwriting the user data stored in a
> definition.  As you've stated, storing a value "into space that hasn't been
> ALLOTted" "isn't guaranteed to" work, but does that relate to 1) just
> storing the value and say a COMMA storing another value there thereby
> changing the originally stored value, or 2) does that apply to something
> else corrupting a definition, e.g., parsing?  The latter is what is going on
> in bigForth.  Gforth and Win32Forth do not update DP either.  They don't
> corrupt the stored value in the definition.  They do overwrite the initial
> value with another when someone uses a COMMA, or permanently allocate the
> initial value when someone uses ALLOT.
> 
>> There is nothing to fix. Bigforth is working as it should.
>>
> 
> I think you misunderstood what I said.
> 
> 
> Rod Pemberton

Look how WORD is implemented in bigForth. Mayby, like as in Figforth, it
places the parsed as a counted string at HERE. WORD is regularly used in
the interpreter. Other implementations may place the string somewhere else,
like Gforth and Win32Forth so the string is not placed at HERE and does not
interfere with what you expected after doing CREATE without ALLOT or comma.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

[toc] | [prev] | [next] | [standalone]

#9242

Coos Haak <chforth@hccnet.nl> writes:
>Look how WORD is implemented in bigForth. Mayby, like as in Figforth, it
>places the parsed as a counted string at HERE. WORD is regularly used in
>the interpreter. Other implementations may place the string somewhere else,
>like Gforth and Win32Forth so the string is not placed at HERE and does not
>interfere with what you expected after doing CREATE without ALLOT or comma.

In Gforth WORD places the string HERE, but the text interpreter does
not use WORD.  Indeed the text interpreter does not copy the string
anywhere, so it never performs more MOVEs than classic Forths and in
many cases performs fewer MOVEs; e.g., in the frequent case when the
text interpreter just looks up the word to perform its interpretation
or compilation semantics (which is probably the vast majority of
what parsing is used for in Forth).

- 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 2011: http://www.euroforth.org/ef11/

[toc] | [prev] | [next] | [standalone]

#9244

Op Thu, 26 Jan 2012 15:37:48 GMT schreef Anton Ertl:

> Coos Haak <chforth@hccnet.nl> writes:
>>Look how WORD is implemented in bigForth. Mayby, like as in Figforth, it
>>places the parsed as a counted string at HERE. WORD is regularly used in
>>the interpreter. Other implementations may place the string somewhere else,
>>like Gforth and Win32Forth so the string is not placed at HERE and does not
>>interfere with what you expected after doing CREATE without ALLOT or comma.
> 
> In Gforth WORD places the string HERE, but the text interpreter does
> not use WORD.  Indeed the text interpreter does not copy the string
> anywhere, so it never performs more MOVEs than classic Forths and in
> many cases performs fewer MOVEs; e.g., in the frequent case when the
> text interpreter just looks up the word to perform its interpretation
> or compilation semantics (which is probably the vast majority of
> what parsing is used for in Forth).
> 
> - anton

The same here. My text interpreter doesn't use WORD and FIND either. Like
as in Gforth I leave the parsed string alone in the input line, by using
PARSE-NAME. I have WORD as a loadable extension
Another reason to work this way is that counted strings are more difficult
to use than address and length pairs on the stack.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

[toc] | [prev] | [next] | [standalone]

#9240

"Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
>The issue is with
>bigForth's parsing related data overwriting the user data stored in a
>definition.

A standard system is allowed to do that, and classic Forth
implementations (e.g., fig-Forth) usually did that.  So, unless
bigForth guarantees that it does not do that, it's not a bug; you can
consider it a quality-of-implementation issue.

- 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 2011: http://www.euroforth.org/ef11/

[toc] | [prev] | [next] | [standalone]

#9211

Rod Pemberton wrote:
>
> CREATE ORANGES 1 ORANGES ! ORANGES @ .
>
...
>
> The ORANGE example fails because DP isn't moved after storing the number.
> The number is being overwritten with parsed data.
>
> CREATE ORANGES
> 1 ORANGES !
> ORANGES @ .

Well, my system throws a "Invalid memory address" for this, at the !.
Because you are attempting to access memory that has not been allocated
to the Forth memory model.

> If one ALLOTS, replacing ORANGE with PEARS to prevent a name collision,  
> then the second sequence works.
>
> CREATE PEARS
> 1 PEARS 1 CELLS ALLOT !
> PEARS @ .

This overcomes the problem because allot extends the Forth memory model
to include the additional cell.  In my system this has nothing what so
ever to do with parsing.  The parsing happens in a completely separate
area of the memory space and is only copied into the Forth memory space
when required by the parsing words.


> How do I know all this?

I am not sure you do.  bigForth may well act in the manner you describe,
but I have just pointed to a completely different cause for you error.
I would also say that I do not consider this to be an error.  A standard
program should not be able to access memory it has not allocated, or
caused to be allocated (via a parsing word).  To do so would be an
environmental dependency.  The oranges example is just such a dependency.

-- 
Peter Knaggs

[toc] | [prev] | [next] | [standalone]

#9217

On Jan 24, 11:26 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> Bernd Paysan,
>
> I know you're not fond of my statements, but I'm probably helping you out
> with this bug report.  Are you aware of the following issue?
>
> I noticed an interesting bug with your ANS bigForth v2.3.1 and v2.4.0.
> bigForth is overwriting data in some words.  Apparently, it's writing parsed
> data to DP or HERE, like the fig-Forth code does.  However, the DP
> dictionary-pointer or HERE is not being adjusted via an ALLOT.
>
> These are two of my test sequences which work for GForth and Win32Forth:
>
> CREATE GRAPES 1 , GRAPES @ .
>
> CREATE ORANGES 1 ORANGES ! ORANGES @ .
>
> The GRAPES example works because DP is adjusted via the , COMMA.
>
> CREATE GRAPES
> 1 ,
> GRAPES @ .
>
> The ORANGE example fails because DP isn't moved after storing the number.
> The number is being overwritten with parsed data.
>
> CREATE ORANGES
> 1 ORANGES !
> ORANGES @ .
>
> If one ALLOTS, replacing ORANGE with PEARS to prevent a name collision, then
> the second sequence works.
>
> CREATE PEARS
> 1 PEARS 1 CELLS ALLOT !
> PEARS @ .
>
> How do I know all this?  My fig-Forth based interpreter is doing the exactly
> same thing ...  The adjustment via ALLOT is the same too.  Apparently, there
> is a difference in where some Forths copy their parsed data.  fig-Forth code
> copies straight to DP or HERE.  Unfortunately, the one fig-Forth for DOS I
> tested had some other failure recognizing CREATE words.  I'll attempt to
> test on another fig-Forth to see if fig-Forth actually has the issue.  I may
> not report the results here though ...
>
> At least you now know what the issue is and can fix it ...
>
> Rod Pemberton

GRAPES and ORANGES both worked in my Forth system. But why do you
think that ! should adjust DP? ! is a poke - it's not a concatenating
action.

[toc] | [prev] | [next] | [standalone]

#9224

"Mark Wills" <markrobertwills@yahoo.co.uk> wrote in message
news:b84391c8-556a-4b83-9990-b5288b8525dd@i25g2000vbt.googlegroups.com...
> On Jan 24, 11:26 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
...

> > The ORANGE example fails because DP isn't moved after storing
> > the number. The number is being overwritten with parsed data.
>
[...]

> GRAPES and ORANGES both worked in my Forth system. But why do you
> think that ! should adjust DP? ! is a poke - it's not a concatenating
> action.

I don't.  I don't "think that ! should adjust DP".  Apparently, I wasn't
clear enough since Ms. Rather thought I said the same.  When DP isn't moved
and Forth parsing writes to HERE or DP, then the ORANGE example fails for
bigForth.  It suceeds for Win32Forth and GForth.  This indicates they use a
different location or buffer instead of writing parsed output to HERE or DP.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#9230

On 1/25/12 6:01 AM, Rod Pemberton wrote:
> "Mark Wills"<markrobertwills@yahoo.co.uk>  wrote in message
> news:b84391c8-556a-4b83-9990-b5288b8525dd@i25g2000vbt.googlegroups.com...
>> On Jan 24, 11:26 pm, "Rod Pemberton"<do_not_h...@noavailemail.cmm>
>> wrote:
> ...
>
>>> The ORANGE example fails because DP isn't moved after storing
>>> the number. The number is being overwritten with parsed data.
>>
> [...]
>
>> GRAPES and ORANGES both worked in my Forth system. But why do you
>> think that ! should adjust DP? ! is a poke - it's not a concatenating
>> action.
>
> I don't.  I don't "think that ! should adjust DP".  Apparently, I wasn't
> clear enough since Ms. Rather thought I said the same.  When DP isn't moved
> and Forth parsing writes to HERE or DP, then the ORANGE example fails for
> bigForth.  It suceeds for Win32Forth and GForth.  This indicates they use a
> different location or buffer instead of writing parsed output to HERE or DP.

Whether they do or not doesn't change the principle: there is no 
protection whatever for space that hasn't been ALLOTted, and you 
shouldn't expect any.

Traditionally, all Forths parsed to HERE, because when you're compiling 
there's a strong likelihood that the word will become a name field of a 
new definition and it saves a MOVE.  So this is entirely accepted, 
normal practice.

You should never store or move anything into a space that you haven't 
previously reserved using ALLOT or the equivalent.

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]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web