Stop using non-standard UID_MAX and GID_MAX because a variety of code
uses inclusive comparisons such that the UINT_MAX value aliases on top
of -1 and causes issues. First instance of this reported by Acts1631.
joint work with millert
Stop using non-standard UID_MAX and GID_MAX because a variety of code
uses inclusive comparisons such that the UINT_MAX value aliases on top
of -1 and causes issues. First instance of this reported by Acts1631.
joint work with millert
Stop using non-standard UID_MAX and GID_MAX because a variety of code
uses inclusive comparisons such that the UINT_MAX value aliases on top
of -1 and causes issues. First instance of this reported by Acts1631.
joint work with millert
update to resiprocate-1.14.0, unbreaks build with newer asio
I had to disable building tests due to some errors around sdp and
auto_ptr. Didn't investigate further as wanted to unbreak it quickly.
sysutils/pftop: handle removal of UID_MAX und GID_MAX
The UID_MAX and GID_MAX macros are not portable, their use is prone
to errors, and they will be removed from the OpenBSD headers shortly.
Mirror a corresponding change to pfctl(8).
*/*: handle removal of UID_MAX und GID_MAX
The UID_MAX and GID_MAX macros are not portable, their use is prone
to errors, and they will be removed from the OpenBSD headers shortly.
Correct related mistakes in range handling: UINT_MAX is not a valid
user or group ID.
Do not write multiple assignment of the same value to multiple cmmu registers
as nested assignment in a single statement.
This used to work in the gcc 2 days, but from gcc 3 onwards, because these
registers are declared volatile, this caused register reloads to propagate
the assignment value.
This had been noticed and fixed in arch/luna88k/luna88k/machdep.c 1.135, but
the similar constructs in this file were missed.
Noticed by tsutsuii at netbsd
Do not limit kernel-mode cmmu fault handling to segment and page faults,
there could be write protection faults as well.
The CMU Mach code did not have such a restriction, it had been added by
Nivas while doing the original mvme88k port.
The logic is now the same for kernel and userland.
Noticed by tsutsui at netbsd.
Adjust graceful restart timer handling for multi-AFI/SAFI sessions
The timer is global for all AFI/SAFI but the first EoR would clear the timer
which then can result in stale routes. Instead stop clearing the timer and
use a new flag CAPA_GR_FINISHED. The code no longer clears CAPA_GR_RESTARTING
on EoR but instead sets CAPA_GR_FINISHED and so when the timer fires the
loop over all AFI/SAFI pairs will will skip all the ones that only have
CAPA_GR_RESTARTING set (but no CAPA_GR_FINISHED).
On top of this improve parse_capabilities() by respecting that only the last
instance of the capability matters. Also make sure capa_neg_calc() does not
write anything to capa.neg.grestart if the capability is disabled on our
end.
Reported by N0zoM1z0
OK tb@
