What is the behaviour on "out of memory" for ALLOT et al. ?

[SirWumpus]

What happens when ALLOT, C,, ,, ALIGN, et al. cannot reserve requested data space? I cannot find any description for this error condition in the old Forth 1994 standard or Draft 19-1 in section 3.3.3 Data space (and its rationale) or else where.

• Does the system crash? Fall off the edge of the know world? Some form of ouroboros?
• Is there an assumption of infinity growth? In hosted environment that might be possible, but what of embedded?
• THROW an error, though there does not appear to be any code for out of memory or out of data space; the closest might be -59 ALLOCATE.

[ruv]

What happens when ALLOT, C,, ,, ALIGN, et al. cannot reserve requested data space?

This situation is declared as an ambiguous condition, so it's up to the system what to do in this case.

See 4.1.2 Ambiguous conditions

• insufficient space in the dictionary;

I think, a throw code should be reserved for such a situation.
But anyway, a standard program cannot do much in this case at the moment, except logging and/or saving some data.

A better way is to provide an API that allows a program to avoid such a situation by checking available space and asking for more space by the needs.

The standard word unused ( -- u ) returns the size reservable by allot only. A system can automatically allocate a new memory block for data space if this size is too small.

In some systems additional dictionary partitions can be provide to a program by demand.

[SirWumpus]

insufficient space in the dictionary;

In Draft 19.1 section 4.1.2 Ambiguous conditions insufficient space in the dictionary has been stroked out (removed) from the list. The next closest thing in 4.1.2 to cover this might be:

• addressing a region not listed in 3.3.3 Data space

ALLOT et al. can "claim" to have reserved space that falls beyond the data space, then when an attempt is made to access that area the equivalent of SIGSEGV is reported.

... A system can automatically allocate a new block for data space if this size is too small. ...
In some systems additional dictionary partitions can be provide to a program by demand.

So where possible the system could grow / enlarge the data space as needed, until some absolute limit is reached, in which case it probably not possible to recover cleanly, just write an error to the terminal and terminate.

[ruv]

In Draft 19.1 section 4.1.2 Ambiguous conditions insufficient space in the dictionary has been stroked out (removed) from the list.

I guess it's a work in progress in the frame of getting rid of ambiguous conditions. If an ambiguous condition is removed, then a particular behavior should be specified instead. And in this case the behavior is not specified yet. I think, the intended behavior in this case is to throw an exception with a special throw code.

So where possible the system could grow / enlarge the data space as needed

Yes. The system can even change the address returned by here. The only problem is a moment when it's allowed to do it. Roughly speaking, a system may do it while compiling a definition, and cannot do it when the current definition (i.e. a definition being compiled) is absent, except some edge cases.

[SirWumpus]

The system can even change the address returned by here.

Are you thinking of resize larger the current data space, where the memory location might change (C's realloc()), which would invalidate any values of HERE on the data stack or stored in the data space used by a word prior to enlargement. Creating a link list of data space chunks would work better to keep existing addresses valid and new allotments just come from the next data space chunk.

... a system may do it while compiling a definition, and cannot do it when the current definition (i.e. a definition being compiled) is absent,...

This statement is unclear; refers to "while compiling a definition" and "a definition being compiled" sound like the same thing in two different cases.

[ruv]

Are you thinking of resize larger the current data space, where the memory location might change (C's realloc())

A system by no means is allowed to make a reserved address invalid, or change the content by this address.

Creating a link list of data space chunks would work better

Yes, I mean that, but failed to express my thought clearly ))

---

... a system may do it while compiling a definition, and cannot do it when the current definition (i.e. a definition being compiled) is absent,...

This statement is unclear; refers to "while compiling a definition" and "a definition being compiled" sound like the same thing in two different cases.

In the second time, in parenthesis, it's an explanation what "the current definition" means.

I refer the term "current definition":

• current definition: The definition whose compilation has been started but not yet ended.

In other words, it's the definition that is being compiled.

So, "while compiling a definition" and absence of the current definition — are opposite things.

[gordonjcp]

On Thu, Feb 09, 2023 at 04:22:00AM -0800, Anthony Howe wrote: What happens when `ALLOT`, `C,`, `,`, `ALIGN`, et al. cannot reserve requested data space? I cannot find any description for this error condition in the old Forth 1994 standard or Draft 19-1 in section 3.3.3 Data space (and its rationale) or else where.

AFAIR in oldschool Forth, the top of PAD collides with the bottom of BUFFERS, with hilarious consequences.

…

-- Gordonjcp