On Tue, 29 Jul 1997, Ray Campbell wrote:
> Andrew Helm wrote:
>
> > There are two bugs in zedit.c, in the function zedit_new_zone().
> > Find the lines that read:
> >
> > /*. Make a new zone in memory.*/
> > CREATE(new_table, struct zone_data, top_of_zone_table);
> > new_table[top_of_zone_table + 1].number = 32000;
> > for(i = 0; i <= top_of_zone_table + 1; i++)
> > if(!found)
> > if (i > top_of_zone_table || zone_table[i].number > vzone_num)
> > { found = 1;
> >
> > The first bug is in the line that reads:
> > CREATE(new_table, struct zone_data, top_of_zone_table);
> >
> > Change this line to:
> > CREATE(new_table, struct zone_data, top_of_zone_table+2);
> >
> > The next bug is in the line that reads:
> > for(i = 0; i <= top_of_zone_table + 1;i++);
> >
> > Change this line to
> > for(i = 0; i <= top_of_zone_table;i++);
>
> Ok, this looked great, but is it too good to be true?
> I added this little fix and tested it out, this is what I got:
> I created a new zone and typed show zones
> I see this for the zone I jsut created:
> 32000 (null) Age: 0; Reset: 0 (0); Top:
> 0
> where it should be:
> 33 New Zone Age: 0; Reset: 30(2); Top: 3399
>
> Ok, now, all I could think of was changing the line:
> new_table[top_of_zone_table + 1].number = 32000;
> to
> new_table[top_of_zone_table + 2].number = 32000;
> ^
> to coincide with the previous, but this resulted in an even more
> interesting problem...but thats besides the point...
> Granted, this is all fixed by a reboot, which cleans up show zones and
> shows the right stuff, and I can edit the zone fine, but before I do
> that it tell me there is no zone for that number.
> So I looked in /lib/world/zon (and wld) and the 33.zon and 33.wld's
> where all there...and in the index correctly...so its just something in
> one of those lines in zedit.c
> just to let you know...
> --Ray
It is too good to be true. There are 2 ways to fix this problem.
Fast and dirty (wastes mem) : change:
CREATE(new_table, struct zone_data, top_of_zone_table);
to:
CREATE(new_table, struct zone_data, top_of_zone_table+3);
The correct way:
rewrite the wole inner and outer loop. I'm not kidding. The logic that it
uses is totally flawed. (After tracing it :) The previous post that
suggested +2 is inded correct. It SHOULD be +2 cause thats the correct
size of the table. The problem is that the inner loop will try and access
+3 after it has found its insertion point. Or inner if, or whatever. If
you take the time to sit there and trace it, you can watch it try to
access outside of the array bounds. If you don['t feel like rwriting it,
just change the table size to +3 and waste a row of mem. No biggie.
Wayde
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST