Go to the first, previous, next, last section, table of contents.

Ambiguous conditions

a name is neither a word nor a number:
-13 throw (Undefined word). Actually, -13 bounce, which preserves the data and FP stack, so you don't lose more work than necessary.
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, code space and name space are accessible. 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:
-14 throw (Interpreting a compile-only word). In some cases, you get an execution token for compile-only-error (which performs a -14 throw when executed).
dividing by zero:
typically results in a -55 throw (floating point unidentified fault), although a -10 throw (divide by zero) would be more appropriate.
insufficient data stack or return stack space:
Not checked. This typically results in mysterious illegal memory accesses, producing -9 throw (Invalid memory address) or -23 throw (Address alignment exception).
insufficient space for loop control parameters:
like other return stack overflows.
insufficient space in the dictionary:
Not checked. Similar results as stack overflows. However, typically the error appears at a different place when one inserts or removes code.
interpreting a word with undefined interpretation semantics:
For some words, we defined interpretation semantics. For the others: -14 throw (Interpreting a compile-only word).
modifying the contents of the input buffer or a string literal:
These are located in writable memory and can be modified.
overflow of the pictured numeric output string:
Not checked.
parsed string overflow:
PARSE cannot overflow. WORD does not check for overflow.
producing a result out of range:
On two's complement machines, 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 -55 throw (floatingpoint unidentified fault), although a -10 throw (divide by zero) would be more appropriate. 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, the stacks are not checked and underflows can result in similar behaviour as overflows (of adjacent stacks).
unexpected end of the input buffer, resulting in an attempt to use a zero-length string as a name:
Create and its descendants perform a -16 throw (Attempt to use zero-length string as a name). Words like ' probably will not find what they search. Note that it is possible to create zero-length names with nextname (should it not?).
>IN greater than input buffer:
The next invocation of a parsing word returns a string wih length 0.
RECURSE appears after DOES>:
Compiles a recursive call to the defining word, not to the defined word.
argument input source different than current input source for RESTORE-INPUT:
-12 THROW. Note that, once an input file is closed (e.g., because the end of the file was reached), its source-id may be reused. Therefore, restoring an input source specification referencing a closed file may lead to unpredictable results instead of a -12 THROW. In the future, Gforth may be able to restore input source specifications from other than the current input soruce.
data space containing definitions gets de-allocated:
Deallocation with allot is not checked. This typically resuls in memory access faults or execution of illegal instructions.
data space read/write with incorrect alignment:
Processor-dependent. Typically results in a -23 throw (Address alignment exception). Under Linux on a 486 or later processor with alignment turned on, incorrect alignment results in a -9 throw (Invalid memory address). There are reportedly some processors with alignment restrictions that do not report them.
data space pointer not properly aligned, ,, C,:
Like other alignment errors.
less than u+2 stack items (PICK and ROLL):
Not checked. May cause an illegal memory access.
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):
abort" last word was headerless".
name not defined by VALUE used by TO:
-32 throw (Invalid name argument) (unless name was defined by CONSTANT; then it just changes the constant).
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 and 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.

Go to the first, previous, next, last section, table of contents.