forked from fluffos/fluffos
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathBugs
318 lines (264 loc) · 8.8 KB
/
Bugs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
The internal message passing functions should be cleaned up. Currently, a lot
of stuff calls add_message() directly, while other stuff uses tell_object()
and friends. One consequence of this is that even with INTERACTIVE_CATCH_TELL
defined, not all of the output flows through catch_tell() [ed, for example,
doesn't, as well as some other efuns].
-----
In the MudOS v22a36 the livings efun gives back HIDDEN things too.
I don't know why objects used that strange construction.
I think, it's new form would be more usable.
As i see this HIDDEN stuff has many leaks, like:
you can always create an object that you put into all rooms, and look
for this_player() in the init apply.
So even if you correct all efuns like livings, heartbeats, named_livings
and so on, it will never be perfect.
solve for livings and objects:
------------------------------- cut here ----------------------------------
1831c1831
< int nob, apply_valid_hide, hide_is_valid = 0;
---
> int nob, display_hidden=-1;
1836d1835
< apply_valid_hide = 1;
1844,1848c1843,1845
< if (apply_valid_hide) {
< apply_valid_hide = 0;
< hide_is_valid = valid_hide(current_object);
< }
< if (hide_is_valid)
---
> if (display_hidden==-1)
> display_hidden = valid_hide(current_object);
> if (!display_hidden)
1876c1873
< int display_hidden = 0, t_sz, i,j, num_arg = st_num_arg;
---
> int display_hidden = -1, t_sz, i,j, num_arg = st_num_arg;
1890a1888,1889
> if (display_hidden==-1)
> display_hidden = valid_hide(current_object);
1892,1893d1890
< display_hidden = 1 + !!valid_hide(current_object);
< if (!(display_hidden & 2))
---------------------------------- cut here --------------------------------
Comment: possibly a better solution is to check O_HIDDEN where O_DESTRUCTED
is checked. valid_hide() would be checked when objects load, and would
set a O_CAN_SEE_HIDDEN bit. Then every time we run across a
FRAME_OB_CHANGE, do:
if (current_object & O_CAN_SEE_HIDDEN)
object_mask = O_DESTRUCTED;
else
object_mask = O_DESTRUCTED | O_HIDDEN;
Code elsewhere would then look something like:
if (sv->type == T_OBJECT && (sv->u.ob->flags & object_mask)) {
free_object(sv->u.ob, "...");
*sv = const0;
}
This would be much more effective at preventing objects from detecting the
existence of hidden objects. It would also fix this one:
Various efuns which call valid_hide() don't realize it can error, causing
them to leak if master::valid_hide() throws an error.
-----
If an include file doesn't end in a newline, something screws up in the
linked buffer code, causing odd compile errors.
Line numbers get messed up when files don't end in a newline?
-----
RUNTIME_LOADING needs -rdynamic passed in the link on some OS's?
(reported for a gcc-linux system; possibly a mixed a.out/elf?)
-----
This gives the wrong error message:
unlock the door with the key
Trying interpretation: unlock:the:door:with:the:key:
Trying rule: OBJ with OBJ
parse_rule
parse_obj:
Found noun: door
parse_rule
Matched literal: with
parse_obj:
Found noun: key
parse_rule
we_are_finished
Trying can_unlock_obj_with_obj ...
Trying can_unlock_obj_word_obj ...
Trying can_verb_obj_word_obj ...
Trying can_verb_rule ...
Trying can_unlock_obj_with_obj ...
Return value was: 1
Trying direct_unlock_obj_with_obj ...
Return value was: 1
Trying indirect_unlock_obj_with_obj ...
Return value was: 0
You can't unlock the thing with that.
exiting parse_rule ...
parse_rule
exiting parse_rule ...
parse_rule
we_are_finished
Trying can_unlock_obj_with_obj ...
Trying can_unlock_obj_word_obj ...
Trying can_verb_obj_word_obj ...
Trying can_verb_rule ...
Trying can_unlock_obj_with_obj ...
Return value was: 1
exiting parse_rule ...
Done trying to match OBJ
parse_rule
last match to error ...
Changing last match.
parse_obj:
Found noun: key
parse_rule
we_are_finished
Trying can_unlock_obj_with_obj ...
Trying can_unlock_obj_word_obj ...
Trying can_verb_obj_word_obj ...
Trying can_verb_rule ...
Trying can_unlock_obj_with_obj ...
Return value was: 1
Trying indirect_unlock_obj_with_obj ...
Return value was: 0
You can't unlock the thing with that.
exiting parse_rule ...
parse_rule
exiting parse_rule ...
parse_rule
we_are_finished
Trying can_unlock_obj_with_obj ...
Trying can_unlock_obj_word_obj ...
Trying can_verb_obj_word_obj ...
Trying can_verb_rule ...
Trying can_unlock_obj_with_obj ...
Return value was: 1
Have better match; aborting ...
exiting parse_rule ...
Done trying to match OBJ
parse_rule
Matched literal: with
parse_obj:
Found noun: key
parse_rule
we_are_finished
Trying can_unlock_obj_with_obj ...
Trying can_unlock_obj_word_obj ...
Trying can_verb_obj_word_obj ...
Trying can_verb_rule ...
Trying can_unlock_obj_with_obj ...
Return value was: 1
Trying indirect_unlock_obj_with_obj ...
Return value was: 0
You can't unlock the thing with that.
exiting parse_rule ...
parse_rule
exiting parse_rule ...
parse_rule
we_are_finished
Trying can_unlock_obj_with_obj ...
Trying can_unlock_obj_word_obj ...
Trying can_verb_obj_word_obj ...
Trying can_verb_rule ...
Trying can_unlock_obj_with_obj ...
Return value was: 1
Have better match; aborting ...
exiting parse_rule ...
Done trying to match OBJ
parse_rule
last match to error ...
Literal not found in forward search
parse_rule
last match to error ...
Literal not found in forward search
parse_rule
Ran out of words to parse.
Done trying to match OBJ
There is no door here.
-----
It still seems possible for regexp(explode(read_file(...), "\n"), ...) to
crash, but I can't reproduce it.
-----
#pragma optimize bug:
;; Function room_of
049d: local LV0
049f: !
04a0: || 0006 (04a7)
04a3: transfer_local LV0
04a5: objectp
04a6: !
04a7: branch_when_zero 0003 (04ab)
04aa: return_zero
04ab: branch 0007 (04b3)
04ae: local LV1
04b0: (void)assign_local LV0
04b2: break_point
04b3: local LV0
04b5: environment
04b7: local_lvalue LV1
04b9: assign
04ba: bbranch_when_non_zero 000d (04ae)
04bd: transfer_local LV0
04bf: return
04c0: return_zero
object room_of(object obj) {
object ob;
if(!obj || !objectp(obj)) return 0;
while(ob=environment(obj)) obj=ob;
return obj;
}
-----
heart_beat() is not shadowable
-----
mixed a;
do {} while (a = ({ a, "" }));
Profezzorn@TMI-2
Comment:
It would be nice if things like this, where all the memory (VM too)
is sucked up by a runaway program, didn't cause the driver to
shutdown ("Out of memory").
### Nope, this evals out, need to do more work to make it run out of memory
-Sym (note: which is not the same as if the driver errors with "Out
of memory)
Yet another comment: Whether it evals out or runs out of mem obviously depends
on the ratio of MAX_EVAL_COST to available memory ...
-----
Range/switch search should be binary, not linear. (in LPC->C)
-----
Probably need a test to see if bison's output actually compiles in
./build.Mudos; on a lot of AIX systems bison's use of alloca() fails.
-Beek
-------
One can call private functions in inherited objects via call_out.
------
verbs that no longer have handlers should be deleted from the parser list
---
Line numbers can be screwed up by macro expansion. Consider the following:
#define IGNORE(x)
#define USE_ONCE(x) x
#define USE_TWICE(x) x
// The end of the next line never gets counted.
IGNORE("foo\
bar")
// The end of the next line is counted once.
USE_ONCE("foo\
bar")
// The end of the next line is counted twice.
USE_TWICE("foo\
bar")
So the IGNORE() and USE_TWICE() cases with screw up line numbering.
Fixing this is non-trivial, since macro expansions are reinserted into
the input stream. Outside of quotes, it was handled by replacing
'\n' with ' ' which is semantically equivalent. Inside quotes, one has
to do something like count the newlines as they are parsed, and then
have add_input() keep track of how many artificial newlines it has created,
so these can be ignored, which requires a check every time current_line++
is done ...
There must be a better fix :)
---
codefor int i,j; ({ i++, j})[1]; return i;
;; Function eval_function
0000: break_point
/* Missing:
* local_lvalue LV0
* inc(x)
*/
0001: local LV0
0003: return