.\" 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 \" .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! ..