heart_beat() is not shadowable ----- need a way to tell the driver to try reconnecting to the addr_server after it has gone down and come back up (the addr_server). maybe the driver could just retry every now and then? --john ----- read_file() doesn't guarantee that a "/" is at the start of the filename before passing to valid_read()...same problem might exist with write_file(), read_bytes(), write_bytes(), didn't check yet (ucs_brf@pip.shsu.edu) Comment: This problem is rather common in the driver currently. Internally, filenames have no leading '/'. One should probably be added every time a filename is passed to the mudlib. ----- hm, Linux apparently doesn't let you open a directory for reading. boggle. so all the efuns that read from a file will screw up if you try to use a dir as the file. ack ucs_brf@pip.shsu.edu ----- sprintf.c should probably be rewritten as it has a nasty habit of munging the stack and writing to places without checking the destination type if it's ok; probably should also remove need for setjmp/longjmp; also: err = setjmp(...) is non strict ANSI portable according to SAS tech support for their C compiler (SAS/C) ----- 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) ----- Currently, binaries are not checked to see if they are out of date with respect to the simul_efun object, causing wierd behavior of binaries of the order of the simuls changes, and then a binary is loaded. ------ edit_source should check for the existence of a.out to see if compilation succeeded. The exit code of the compiler is correct alot, but not on all systems. Should probably use -o somefile instead of assuming a.out as well. ----- Line numbers get messed up when files don't end in a newline? ----- 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 alot of AIX systems bison's use of alloca() fails. -Beek ------- The current implementation of swapping could use alot of work. Swapping an object in/out isn't that expensive CPU wise, and can save a decent amount of memory. The problem is that cloned programs can't swap, which disables swapping for much of the mud ... -Beek ----- eval string s = "xyz"; s[1] = 0; return s + "foo"; Isn't handled right, since after s[1] = 0 the length is still 3. Several possible ways to fix this: (1) allow strings to contain zero, and nuke the buffer type (requires a number of mods like strcpy() -> memcpy() throughout the source) (2) claim that assigning 0 to a char lvalue is a runtime error (the easy way out :) ) (3) Actually truncate the string and modify it's length. This is really messy b/c it requires char lvalues to keep a pointer to the start as well, and also is somewhat counterintuitive. --- One can call private functions in inherited objects via call_out. --- livings() and heart_beats() don't obey set_hide() --- 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 :)