8.1.2 Ambiguous conditions

a name is neither a word nor a number:

If a recognizer matches (see recs, see Default recognizers, see Literals in source code), the text interpreter performs its interpreting, compiling, or postponing action (which one, depends on the state). If none matches, the text interpreter performs -13 throw (Undefined word).

a definition name exceeds the maximum length allowed:

-19 throw (Word name too long)

addressing a region not inside the various data spaces of the forth system:

The stacks, data space, code space and header space are readable and writable. Machine code space is typically readable. Accessing other addresses gives results dependent on the operating system. On decent systems: -9 throw (Invalid memory address).

argument type incompatible with parameter:

This is usually not caught. Some words perform checks, e.g., the control flow words, and issue a ABORT" or -12 THROW (Argument type mismatch).

attempting to obtain the execution token of a word with undefined execution semantics:

You get an execution token that represents the interpretation semantics of the word. In some cases, the standard does not define the interpretation semantics nor the execution semantics (e.g., if). In those cases, you get an execution token for the compilation semantics. For words marked compile-only, the most common ways of obtaining the xt produce a warning.

dividing by zero:

On some platforms, this produces a -10 throw (Division by zero); on other systems, this typically results in a -55 throw (Floating-point unidentified fault). On some platforms, the gforth-fast engine produces some hardware-dependent value.

insufficient data stack or return stack space:

Depending on the operating system, the installation, and the invocation of Gforth, this is either checked by the memory management hardware, or it is not checked. If it is checked, you typically get a -3 throw (Stack overflow), -5 throw (Return stack overflow), or -9 throw (Invalid memory address) (depending on the platform and how you achieved the overflow) as soon as the overflow happens. If it is not checked, overflows typically result in mysterious illegal memory accesses, producing -9 throw (Invalid memory address) or -23 throw (Address alignment exception); they might also destroy the internal data structure of ALLOCATE and friends, resulting in various errors in these words.

insufficient space for loop control parameters:

Like other return stack overflows.

insufficient space in the dictionary:

If you try to allot (either directly with allot, or indirectly with ,, create etc.) more memory than available in the dictionary, you get a -8 throw (Dictionary overflow). If you try to access memory beyond the end of the dictionary, the results are similar to stack overflows.

interpreting a word with undefined interpretation semantics:

Gforth defines interpretation semantics for all words; for words where the standard defines execution semantics (except exit and leave), the interpretation semantics are to perform the execution semantics. For words where the standard defines no interprtation semantics, but defined compilation semantics (plus exit and leave), the interpretation semantics are to perform the compilation semantics. Some words are marked as compile-only, and text-interpreting them gives a warning.

modifying the contents of the input buffer or a string literal:

These are located in writable memory and can be modified, which may have bad consequences for later execution.

overflow of the pictured numeric output string:

-17 throw (Pictured numeric output string overflow).

parsed string overflow:

PARSE cannot overflow. WORD does not check for overflow.

producing a result out of range:

Arithmetic is performed modulo 2**bits-per-cell for single arithmetic and 4**bits-per-cell for double arithmetic (with appropriate mapping for signed types). Division by zero typically results in a -10 throw (divide by zero) or -55 throw (floating point unidentified fault). Overflow on division may result in these errors or in -11 throw (result out of range). Gforth-fast may silently produce bogus results on division overflow or division by zero. Convert and >number currently overflow silently.

reading from an empty data or return stack:

The data stack is checked by the outer (aka text) interpreter after every word executed. If it has underflowed, a -4 throw (Stack underflow) is performed. Apart from that, stacks may be checked or not, depending on operating system, installation, and invocation. If they are caught by a check, they typically result in -4 throw (Stack underflow), -6 throw (Return stack underflow) or -9 throw (Invalid memory address), depending on the platform and which stack underflows and by how much. Note that even if the system uses checking (through the MMU), your program may have to underflow by a significant number of stack items to trigger the reaction (the reason for this is that the MMU, and therefore the checking, works with a page-size granularity). If there is no checking, the symptoms resulting from an underflow are similar to those from an overflow. Unbalanced return stack errors can result in a variety of symptoms, including -9 throw (Invalid memory address) and Illegal Instruction (typically -260 throw).

unexpected end of the input buffer, resulting in an attempt to use a zero-length string as a name:

Create and its descendants, as well as ' and friends perform a -16 throw (Attempt to use zero-length string as a name) if they are invoked at the end of a line. However, it is possible to create zero-length names with nextname.

>IN greater than input buffer:

The next invocation of a parsing word returns a string with length 0.

RECURSE appears after DOES>:

Compiles a recursive call to the code after DOES>.

argument input source different than current input source for RESTORE-INPUT:

Ideally, this should result in a -12 THROW. Currently it produces unintended results (up to and including terminating the Gforth session).

data space containing definitions gets de-allocated:

Deallocation with allot is not checked, possibly resulting in system corruption. If you deallocate to the section-start, you get a -8 throw (dictionary overflow).

data space read/write with incorrect alignment:

Processor-dependent. Typically results in a -23 throw (Address alignment exception). There are reportedly some processors with alignment restrictions that do not report violations, but just produce unintended results.

data space pointer not properly aligned, ,, C,:

Like other alignment errors.

less than u+2 stack items (PICK and ROLL):

Like other stack underflows.

loop control parameters not available:

Not checked. The counted loop words simply assume that the top of return stack items are loop control parameters and behave accordingly.

most recent definition does not have a name (IMMEDIATE):

No effect.

name not defined by VALUE used by TO:

If to is not supported by the word type: -21 throw (Unsupported operation).

name not found (', POSTPONE, ['], [COMPILE]):

-13 throw (Undefined word)

parameters are not of the same type (DO, ?DO, WITHIN):

Gforth behaves as if they were of the same type. I.e., you can predict the behaviour by interpreting all parameters as, e.g., signed.

POSTPONE or [COMPILE] applied to TO:

Assume : X POSTPONE TO ; IMMEDIATE. X performs the compilation semantics of TO.

String longer than a counted string returned by WORD:

Not checked. The string will be ok, but the count will, of course, contain only the least significant bits of the length.

u greater than or equal to the number of bits in a cell (LSHIFT, RSHIFT):

Processor-dependent. Typical behaviours are returning 0; or using only the low bits of the shift count.

word not defined via CREATE:

>BODY produces the PFA of the word no matter how it was defined.

DOES> changes the execution semantics of the last defined word no matter how it was defined. E.g., CONSTANT DOES> is equivalent to CREATE , DOES>.

words improperly used outside <# and #>:

Not checked. As usual, you can expect memory faults.