appA 14 KB

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