Bug: Global weath_unit value is not properly validated.
Danger: Critical - Crashes if set to zero. Numerous unchecked divisional uses.
Discovered in: AFKMud 1.77
Found by: Remcon
Fixed by: Remcon

---

db.c, do_setweather

Locate:

   else if( !str_cmp( arg, "unit" ) )
   {
      if( !is_number( argument ) )
      {
         ch_printf( ch, "Set weather unit " "size to what?\r\n" );
      }
      else
      {
         weath_unit = atoi( argument );
         ch_printf( ch, "Weather unit size " "now equals %d.\r\n", weath_unit );
         save_weatherdata(  );
      }
   }

Change to:

   else if( !str_cmp( arg, "unit" ) )
   {
      if( !is_number( argument ) )
         ch_printf( ch, "Set weather unit size to what?\r\n" );
      else
      {
         int unit = atoi( argument );

         if( unit == 0 )
         {
            send_to_char( "Weather unit size cannot be zero.\r\n", ch );
            return;
         }
         weath_unit = unit;
         ch_printf( ch, "Weather unit size now equals %d.\r\n", weath_unit );
         save_weatherdata(  );
      }
   }

db.c, load_weatherdata

Locate:

         else if( !str_cmp( word, "UNIT" ) )
            weath_unit = fread_number( fp );

Change to:

         else if( !str_cmp( word, "UNIT" ) )
         {
            int unit = fread_number( fp );

            if( unit == 0 )
               unit = 1;

            weath_unit = unit;
         }

While this fix may not look espeicially bad, it will become crystal clear after setting this value to 0. There are numerous places in the weather related code that use weath_unit as a divisor. Dividing by zero is a Bad Thing(tm) and will bring your came crashing down rather abruptly. Since this value is also saved upon being set, it may make it difficult to get the mud back up when one does not realize why there's a problem.