macro in dns_rdataclass_fromtext by using an intermediate variable
to hold the constant 2nd argument in each use.
added the RESERVED attribute to the reserved0 class in the same function.
the logconfig is properly dimensioned, and only free the channellist
memory in isc_logconfig_destroy if the channellist_count is > 0.
the first addresses a problem that could occur when a successful
isc_log_create was followed immediately by isc_log_[v]write[1] or
isc_log_destroy (with no intervening isc_log_usechannel or
isc_logconfig_use), and the second addresses a problem that could
occur in cleanup if isc_log_create or isc_logconfig_create failed.
reversing part of the changes made on 2000/05/17. Doing an explicit
zone shutdown on destruction of the zone table caused the zone to
be shut down prematurely on server reload when the zone table was
destroyed but the zone had already been attached to a new zone table.
An external reference count is needed to correctly handle this situation.
invariant, causing timer events not to be posted
when due.
Specifically, isc_heap_delete() moved the last element of the heap to
the vacated position and then attempted to restore the heap invariant
by calling sink_down(). This works when the last element has a lower
priority than the one being deleted, and this is often the case
because the last element tends to have a low priority. However, it is
not guaranteed to be the lowest. When deleting an item of a lower
priority than the last item, restoring the invariant requires a call
to float_up(), not sink_down().
isc_heap_delete_now calls either float_up() or sink_down() as needed,
and INSISTs have been added to verify that the heap invariant indeed
holds after the calls.
zone->expire instead of zone->expiretime. This left zone->expiretime
with a value of zero, causing zone_settimer() to get horribly confused
and set the timer to the inactive state (!). This in turn caused
notify-driven refreshes (and probably other timer-scheduled events, too)
to never happen.
are any problems in a validation, a SERVFAIL will be returned. This may not
be correct in all cases (and will be fixed), but it leaves the server in a
much more consistent state after failures.
