ack/doc/int/appA

.\"	List of all warnings; source of warn_msg and warn.h
.\"
.\"	$Id$
.\"
.\"	This file contains the warnings issued by the interpreter, together
.\"	with their names and values in the code of the interpreter. Some of
.\"	the source files of the interpreter are generated from the Wn
.\"	macros in this file.
.\"	When modifying this file, preserve the parameters of the Wn macros.
.de Wn	\" <text> <define> <value>
.IP \\$3. 7
.B "\\$1"
.br
..  Wn
.bp
.DS C
APPENDIX A
.DE
.SH
List of Warnings.
.PP
The shadow-byte administration makes it possible to check for a
wide range of errors during run-time.
We have tried to make the diagnostics self-explanatory and especially useful
for the C-programmer.
The warnings are printed in the message file, together with source file
and line number.
The complete list of warnings is presented here, followed by an
explanation of what might be wrong.
Often, these explanations implicitly assume that the program
being interpreted, was originally written in C (and not Pascal, Basic etc.).
.LP
.I "Reading the load file"
.Wn "Floating point instructions flag in header ignored" WFLUSED 1
.Wn "No float initialisation in this version" WFLINIT 2
The interpreter was compiled with the NOFLOAT option; code involving
floating point operations can be run as long as the actual
instructions are avoided.
.Wn "Extra-test flag in header ignored" WEXTRIGN 4
The interpreter already tests anything conceivable.
.Wn "Maximum line number in header was 0" WNLINEZR 5
This number could be used to allocate tables for tallying; these tables are,
however, expanded as needed, so the number is immaterial.
.Wn "Bad float initialisation" WBADFLOAT 7
The loadfile contains a floating point denotation which does not
satisfy the syntax (see 2.6).
Examining the loadfile (with \fBod \-c\fP) might show the syntax error.
Probably there is a bug in the front-end, creating floats with
a bad syntax.
.LP
.I "System calls"
.Wn "IOCTL \- bad or unimplemented request" WBADIOCTL 11
The second parameter to the ioctl() request (the operation code) is invalid or
not implemented; since there are many different opcodes on the various UNIX
systems, it is difficult to tell which.  The system call fails.
.Wn "MPXCALL \- not (yet) implemented" WMPXIMP 14
.Wn "PROFIL \- not (yet) implemented" WPROFILIMP 15
.Wn "PTRACE \- not (yet) implemented" WPTRACEIMP 16
The monitor calls \fImpxcall()\fP, \fIprofil()\fP and \fIptrace()\fP
have not been implemented.  The monitor call fails.
.Wn "Inaccessible memory in system call" WMONFLT 21
Bad pointers passed to system calls do not cause a memory fault (which in UNIX
would happen to the kernel), but cause the system call to fail with the UNIX
variable errno set to 14 (EFAULT).  It seems likely that the program is at
fault, but there is also a good possibility that a library routine made
unwarranted assumptions about word size and pointer size.
.Wn "READ \- buffer resides in unallocated memory" WRUMEM 23
.Wn "READ \- buffer across global data area and heap" WRGDAH 24
When the buffer passed to the read() system call is situated (completely
or partially) in unallocated memory (beyond \fIHP\fP) or begins
in the global data area and ends in the heap, the appropriate warning
is given.
The buffer is not written.
.Wn "WRITE \- buffer resides in unallocated memory" WWUMEM 25
.Wn "WRITE \- buffer across global data area and heap" WWGDAH 26
.Wn "WRITE \- (part of) global buffer is undefined" WWGUNDEF 27
.Wn "WRITE \- (part of) local buffer is undefined" WWLUNDEF 28
The first two are equivalent to the READ-errors above.
Writing out a buffer usually makes no sense when the contents are undefined,
so one of the latter two warnings will be generated in this case.
A global buffer resides in the data partition; a local buffer resides in
the stack partition.
This corresponds to global and local variables in a C-program.
In the first two cases the WRITE is not performed, in the latter two cases
it is.
.LP
.I "Traps and signals"
.Wn "SIGTRP \- bad signo argument" WILLSN 31
The \fIsigtrp()\fP monitor call allows \fIsig_no\fP arguments in the
range [1..17] (UNIX Version 7 signals); the actual argument is out of range.
.Wn "SIGTRP \- signo argument is a synchronous trap" WUNIXTR 32
The signal is one that can only be caused synchronously by the running program
on UNIX; it cannot occur to an interpreted program.
.Wn "SIGTRP \- bad trapno argument" WILLTN 33
The \fIsigtrp()\fP monitor call allows \fItrap_no\fP arguments between 0 and
252, and the special values \-2 and \-3; the actual argument is not one of
these.
.Wn "Heap overflow due to command line limitation" WEHEAP 36
.Wn "Stack overflow due to command line limitation" WESTACK 37
The maximum sizes of the heap and the stack can be limited by options on the
command line.  If overflow occurs due to such limitations, the corresponding
trap is taken, preceded by one of the above warnings.  If the memory of the
interpreter itself is exhausted, a fatal error follows.
.LP
.I "Run-time type checking"
.Wn "Local character expected" WLCEXP 41
.Wn "Global character expected" WGCEXP 42
.Wn "Local integer expected" WLIEXP 43
.Wn "Global integer expected" WGIEXP 44
.Wn "Local float expected" WLFEXP 45
.Wn "Global float expected" WGFEXP 46
.Wn "Local data pointer expected" WLDPEXP 47
.Wn "Global data pointer expected" WGDPEXP 48
.Wn "Local instruction pointer expected" WLIPEXP 49
.Wn "Global instruction pointer expected" WGIPEXP 50
In general, a type violation has taken place when one of
these warnings is given.
The \fBfloat\fP- and \fBinstruction pointer\fP warnings are rare and will
usually be easy traceable.
\fBInteger/character expected\fP will normally occur when unsigned arithmetic
is performed on datapointers or when memory containing objects other than
integers is copied bytewise.
Often, this warning is followed by a warning \fBdatapointer expected\fP.
This is due to our decision of transforming pointers to (unsigned) integers
after doing unsigned arithmetic on them.
When such a transformed integer is dereferenced (as if it were a pointer)
or, in general, when it is treated as a pointer, this results in a warning.
The present library implementation of malloc() causes such a
sequence of errors.
.LP
These messages are always followed by a tentative description of what is found
in memory at the offending place.
.Wn "Actual memory is undefined" WWASUND 61
.Wn "Actual memory contains an integer" WWASINT 62
.Wn "Actual memory contains a float" WWASFLOAT 63
.Wn "Actual memory contains a data pointer" WWASDATAP 64
.Wn "Actual memory contains an instruction pointer" WWASINSP 65
.Wn "Actual memory contains mixed information" WWASMISC 66
If the contents of the area was undefined,
check the source code for an uninitialized variable of the mentioned type.
Officially, the use of an undefined value
should result in a EIUND or EFUND trap but the occurrence is
so common that a warning is more appropriate.
The contents of memory are described as mixed if the data consists of pieces
of different types.  This happens, e.g., when caller and callee do not agree on
the types and lengths of the parameters.
.LP
.I "Protection"
.br
.Wn "Destroying contents of ROM (at or near loc 0)" WDESROM 71
The program stores a value in Read-Only Memory; the only ROM in the present
implementation is the area near location 0.  The warning probably results from
storing under a NULL pointer.  This is only a warning, the store operation is
executed normally.  Reads from location 0 are not detected.
.Wn "Destroying contents of Return Status Block" WDESRSB 72
The Return Status Block is the stack area containing the return address, the
dynamic link, etc.
This may or may not be an error.
The current implementation of \fIsetjmp()\fP/\fIlongjmp()\fP
may be responsible for it.
If the program does not use setjmp(), there \fIis\fP something
very wrong (e.g. argument for ASP too large).
Note that there are some library routines (such as \fIalarm()\fP) which
use \fIsetjmp()\fP.
.Wn "Logical operation using undefined operand(s)" WUNLOG 81
.Wn "Comparing undefined operand(s)" WUNCMP 82
The logical operations AND, XOR, IOR, COM and the compare operation
CMS do their jobs bytewise.
If one of the bytes is found to be undefined, the corresponding warning
is given, and the operation is stopped immediately.
The stack is adjusted so interpretation may continue.
.br
It is hard to say what went wrong.
Possibly, the argument of the instruction at hand (which indicates the
size of the objects to be compared), was too large.
.LP
.I "Bad operands"
.Wn "Shift over negative distance" WSHNEG 91
.Wn "Shift over too large distance" WSHLARGE 92
Shift instructions yield undefined results if the shift distance is negative
or larger than the object size.
.Wn "Pointer arithmetic yields pointer to bad segment" WSEGADP 93
When doing pointer arithmetic (ADP, ADS), the operand and result pointer
must be in the same \fIsegment\fP (see sec. 4).
E.g. loading the address of the first local and adding 20 to it will
certainly give this warning.
.Wn "Subtracting pointers to different segments" WSEGSBS 94
Pointers may be subtracted only if they point into the same segment.
.Wn "Pointer arithmetic with NULL pointer" WNULLPA 96
By definition it is illegal to do arithmetic with null pointers.
Integers with the size of a pointer and the value zero are recognized
as NULL pointers.
A well-known C-trick to compute the offset of some field in a struct
is converting the null-pointer to the type of the struct and simply
taking the address of the field.
This trick will \-when translated and interpreted\- generate this warning
because it results in arithmetic with the NULL pointer.
.LP
.I "Return area"
.Wn "Returned function result too large" WRFUNLAR 101
.Wn "Returned function result too small" WRFUNSML 102
This warning is generated when the size of the expected return value
is not equal to the size actually returned.
.br
An interpreted program may have fallen through the end of
the code without explicitly doing an \fIexit()\fP or \fIreturn()\fP.
The start-up routine (\fIcrt0()\fP) however always expects to get some
value returned by the program proper.
.br
Another (less probable) possibility of course is that the code contains
a subroutine or function call that does not return properly (e.g.
it returns a short instead of a long).
.Wn "Returned function result may be garbled" WRFUNGAR 103
This warning will be generated, when the contents of the FRA are fetched
after some instruction is executed which can mess up the area.
Compiler-generated loadfiles should not generate this message.
.LP
.I "Return Status Block"
.Wn "RET did not find a Return Status Block" WRETBAD 111
.Wn "Used RET to return from a trap" WRETTRAP 112
The RET instruction found a garbled Return Status Block, or on that resulted
from a trap.
.Wn "RTT did not find a Return Status Block" WRTTBAD 115
.Wn "RTT on empty stack" WRTTEMPTY 116
.Wn "Used RTT to return from a call" WRTTCALL 117
.Wn "Used RTT to return from a non-returnable trap" WRTTNRTT 118
The RTT (Return from Trap) instruction found a Return Status block that was not
created properly by a trap.
.Wn "Stack Pointer too large in RET" WRETSTL 121
.Wn "Stack Pointer too small in RET" WRETSTS 122
.Wn "Stack Pointer too large in RTT" WRTTSTL 125
.Wn "Stack Pointer too small in RTT" WRTTSTS 126
According to the EM Manual (4.2), "the value of SP just after the return
value has been popped must be the same as the
value of SP just before executing the first instruction of the
invocation."
If the Stack Pointer is too large, some dynamically allocated item or some
temporary result may have been left behind on the stack.
If the Stack Pointer is too small, some locals have been unstacked.
Since the interpreter has enough information in the Return Status Block, it
recovers correctly from these errors.
.LP
.I "Traps"
.LP
Some traps have ambiguous or non-obvious causes.
As far as possible, these are preceded by a warning, explaining the
circumstances of the trap.
.Wn "Trap ESTACK: DCH on bad LB" WDCHBADLB 131
.Wn "Trap ESTACK: LPB on bad LB" WLPBBADLB 132
.Wn "Trap ESTACK: SP retracted over Return Status Block" WSPGTLB 133
.Wn "Trap ESTACK: SP moved into data area" WSPINHEAP 134
.Wn "Trap ESTACK: SP set to non-word-boundary" WSPODD 135
.Wn "Trap ESTACK: LB set out of stack" WLBOUT 136
.Wn "Trap ESTACK: LB set to non-word-boundary" WLBODD 137
.Wn "Trap ESTACK: LB set to position where there is no RSB" WLBRSB 138
.Wn "Trap EHEAP: HP retracted into Global Data Area" WHPGDA 141
.Wn "Trap EHEAP: HP pushed into stack" WHPSTACK 142
.Wn "Trap EHEAP: HP set to non-word-boundary" WHPODD 143
.Wn "Trap EILLINS: unknown opcode" WBADOPC 151
.Wn "Trap EILLINS: conversion with unacceptable size for this machine" WILLCONV 152
.Wn "Trap EILLINS: FIL with non-existing address" WILLFIL 153
.Wn "Trap EILLINS: LFR with too large size" WILLLFR 154
.Wn "Trap EILLINS: RET with too large size" WILLRET 155
.Wn "Trap EILLINS: instruction argument of class c does not fit a word" WARGC 156
.Wn "Trap EILLINS: instruction on double word on machine with word size 4" WARGD 157
.Wn "Trap EILLINS: local offset too large" WARGL 158
.Wn "Trap EILLINS: instruction argument of class g not in GDA" WARGG 159
.Wn "Trap EILLINS: fragment offset too large" WARGF 160
.Wn "Trap EILLINS: counter in lexical instruction out of range" WARGN 161
.Wn "Trap EILLINS: non-existent procedure identifier" WARGP 162
.Wn "Trap EILLINS: illegal register number" WARGR 163
.Wn "Trap EBADPC: jump out of text segment" WPCOVFL 172
.Wn "Trap EBADPC: jump out of procedure fragment" WPCPROC 173
.Wn "Trap EBADGTO: GTO does not restore an existing RSB" WGTORSB 181
.Wn "Trap EBADGTO: GTO descriptor on the stack" WGTOSTACK 182
.Wn "Trap caused by TRP instruction" WTRP 191
.ig
.Wn "Last warning" WMSG 199
!Leave these lines here!
..