pForth, over-indexing a buffer

[papadil]

I discovered pForth and compiled it on a Mac Mini. Works for the most part but there is an annoying bug, when creating a buffer with "create name # allot". The first assignment to the cells in "name" goes ok. But if need to update it a second time I get a "segmentation fault ./pforth_standalone". Same if I use pforth -dpforth.dic. If using 'variable name' there is no problem, I can update it many times. Just letting you guys know. Don't know how to debug it otherwise I would try to find where the problem lies.

[philburk]

I tried this on my Mac.

create foo 16 allot
1234 foo !
foo @ .
98765 foo !
foo @ .

I printed 1234 and 98765, as expected.

Can you give me the exact steps that would reproduce this problem?

Note that a CELL may be 8 bytes. So if you ALLOT less than 8 bytes you might overflow the bounds of foo.

[papadil]

I had a loop filling an array (btw I use cells and cells+ to allocate) and rewriting the array crashed pforth. I did note that the loop was addressing one more cell than I had allocated. That was what made it crash, on the second pass. It did not crash on the first access off the bottom of the array but on the second - that’s why it took me a while to detect the +1 error in the code. Thanks.

…

On May 11, 2024, at 5:20 PM, Phil Burk ***@***.***> wrote: I tried this on my Mac. create foo 16 allot 1234 foo ! foo @ . 98765 foo ! foo @ . I printed 1234 and 98765, as expected. Can you give me the exact steps that would reproduce this problem? Note that a CELL may be 8 bytes. So if you ALLOT less than 8 bytes you might overflow the bounds of foo. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[papadil]

I have the following recursive definition and called as “5 3 rp”; it causes a segmentation fault. The recursion shouldn’t be too deep for this call. Any ideas? Much appreciated. : rp { n k -- p(n) } n 0= k 0= and if 1 else n 0< k 0< or if 0 else n k - k recurse n 1- k 1- recurse + then then ; Thanks

[papadil]

Never mind - I found the bug - one condition was missing so it caused a stack overflow.

…

On Jun 4, 2024, at 6:24 PM, P Padil ***@***.***> wrote: I have the following recursive definition and called as “5 3 rp”; it causes a segmentation fault. The recursion shouldn’t be too deep for this call. Any ideas? Much appreciated. : rp { n k -- p(n) } n 0= k 0= and if 1 else n 0< k 0< or if 0 else n k - k recurse n 1- k 1- recurse + then then ; Thanks