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 :)