BUG LIST WITH FIXES

From: Ryan (ed209@iia2.org)
Date: 07/22/95


This file will generally outline some of the generic circlemud tweks and bugs
I've found today.  They are by no means all 100% correct, so if someone sees
room for improvement, please speak up :).

---

Problem: This bug has to do with not initializing the structure "sa" to begin
         with.

Fix:

comm.c:

#endif

+ bzero((char *) &sa, sizeof(sa));

  sa.sin_family = AF_INET;
  sa.sin_port = htons(port);

---

Problem: In utils.c, there are two functions named:
           - struct time_info_data real_time_passed(time_t t2, time_t t1);
           - struct time_info_data mud_time_passed(time_t t2, time_t t1);

         In both cases, they are configured to return a variable named "now",
         a structure.  This can easily get corrupted and begin to point to
         garbage the way it is at this point in circlemud beta, so
         here's what you do to fix it..  (BTW, I know there is a much better
         way to fix this problem, but I'm too lazy.. there's still too many
         generic bugs that need fixing).. If someone finds a better way to
         remedy it, please share it with us.

Fix:

utils.c:

struct time_info_data mud_time_passed(time_t t1, time_t t2)
{
  long secs;
- struct time_info_data now;
+ static struct time_info_data now;

  secs = (long) (t2 - t1);

utils.c:

struct time_info_data mud_time_passed(time_t t1, time_t t2)
{
  long secs;
- struct time_info_data now;
+ static struct time_info_data now;

  secs = (long) (t2 - t1);

---

Problem: One problem I've had with circlemud is when assigning the shopkeepers,
         if the shopkeeper's vnum does not exist, the function
         (assign_the_shopkeepers()) will cause a block bounds violation in the
         heap.  This is not fatal on most compiliers, however it may cause
         problems in very remote circumstanes.  I haven't wrote a fix for this
         because it was really my fault that something like this arose.. but
         I'm sure it happens to alot of people.  Surely Jermey could write a
         protection code to stop this from happening.

Fix: None as of yet.

---

Problem: Loading initiazied variables on to the stack when writing them to
         a file.  There are two occurances I've seen of this.. one in
         Obj_to_store(), another in the save_char().

Fix:

db.c:

void save_char(struct char_data * ch, sh_int load_room)
{
  struct char_file_u st;

  if (IS_NPC(ch) || !ch->desc || GET_PFILEPOS(ch) < 0)
    return;

+ memset((char *) &st, 0, sizeof(struct char_file_u));

  char_to_store(ch);

objsave.c:

int Obj_to_store(struct obj_data * obj, FILE *fl)
{
  int j;
  struct obj_file_elem object;

+ memset((char *) &object, 0, sizeof(struct obj_file_elem));

  object.item_number = GET_OBJ_VNUM(obj);

---

Thats all the bugs I have documentated for now.  There are lots more to
come.  Note that most of these bugs will not effect your mud in most
conditions.  But remember, fatal bugs memory leaks are 99% of the time due
to smaller minor bugs.  Also, I do not take any responsibility for any
damage these modifications might do to your system or code.  Although
I have tested them on my version, and they should not be damaging at all,
I just like to have some protection just in case sometimes tries to blame
me for something.

Ryan, aka..

Morbid of Vortex MUD - arcade.com 8888 (199.3.240.54 8888)
                     - ed209@maxwell.iia2.org / vortex@arcade.com



This archive was generated by hypermail 2b30 : 12/07/00 PST