The code that has been removed was not reachable from after the Var_Parse
call. All branches after the Var_Parse are either freed properly or
return the expanded value.
The details of parsing are quite tricky and not documented in the manual
page. Record the current behavior to be a little safer in future
refactorings.
(epp->ep_esch->es_emul == &emul_netbsd32) to determine whether curlwp is
running on COMPAT_NETBSD32 or not.
The former is possible even if COMPAT_NETBSD32 is not built in the main
kernel. Now, compat_netbsd32 module can work on !COMPAT_NETBSD32 kernel.
Discussed with pgoyette.
XXX
Apply similar fixes, i.e., drop ``#ifdef COMPAT_NETBSD32'' conditional
codes from the rest parts of MD codes for aarch64 and mips64.
Warp is a real-time space war game that doesn't get boring very quickly.
Read warp.doc and the manual page for more information.
games/warp originally distributed with 4.3BSD-Reno, is back to the BSD
world via NetBSD. Its remnants were still mentioned in games/Makefile.
Larry Wall, the original author and the copyright holder, generously
donated the game and copyright to The NetBSD Foundation, Inc.
Import the game sources as-is from 4.3BSD-Reno, with the cession
of the copyright and license to BSD-2-clause NetBSD-style.
Signed-off-by: Larry Wall <larry@wall.org>
Signed-off-by: Kamil Rytarowski <kamil@netbsd.org>
the implementation stuff in a variable CTFCONVERT_RUN
- introduce an OBJECT_TARGET variable that contains the output object file
- when we need to run ctfconvert, go through an intermediate ${.TARGET}.o
file, instead of writing directly to ${.TARGET} and then overwriting
${.TARGET} with ctfconvert. This avoids build failures after a build
got interrupted (the "partially built from C" scourge).
It needs the (8), or it fails to work for people who don't know or had
forgotten catman(8) was ever a thing.
as the de facto fortunes editor and also I think the person who added
that fortune in the first place, and given the discussion in
tech-userlevel, I think I get to do this.
The lint option affects much more than a typical debug flag. Not only
does it produce additional diagnostics, it also changes the control flow
and fixes the traditional error handling in a few places.
No functional change.
